DevPortal

How does Pramati Naming Service Cache on Client-Side?

Table of Contents

Pramati Naming Service provides caching on client-side. When an object is looked up from the Naming Service, it is cached on client-side and returned for subsequent lookups. Since all Server-side bindings are within the same VM, lookups are treated as local calls and performance is improved.

In a cluster environment, caches are intelligently refreshed in case of failure of a Server node.

How does Pramati Naming Service Support Hierarchy?

Pramati Naming Service supports hierarchy.

For example, a lookup for ctx.lookup("java:comp/env/jdbc/MyDb"); is split into Context envCtx = ctx.lookup("java:comp/env"); and envCtx.lookup("jdbc/MyDb");. Also, the lookup ctx.lookup("myBean/EJB"); may be split into Context myCtx = ctx.lookup("myBean"); and myCtx.lookup("EJB");.

Which Object Types can I Bind in the Naming Service?

Objects that can be bound in the Naming Service are:

What is UserTransaction Support?

To lookup the user transaction object in your application, use the standard J2EE name: java:comp/UserTransaction

What is the Initial Context Factory?

Developers writing clients to Pramati Server must specify an initial context factory com.pramati.naming.client.PramatiClientContextFactory in the client code. This context factory contacts the Server and determines whether the Server is configured as a standalone node or a cluster node and returns the appropriate context to the client. While writing clients, one need not change the context factory depending on Server mode.

The context for standalone node connects to the Naming Service on Server, and all context operations such as lookup, bind, and unbind are performed on it, assuming that all required permissions have been granted. Normally, only lookup permissions are granted to clients. The context for Pramati cluster contains logic for load balancing and failover.

What are the properties for InitialContext?

When creating an InitialContext from Java or Web clients, various properties can be specified for different behavior of the context.

com.pramati.dns

This specifies the DNS to contact to get the list of server nodes. The DNS configured should be mapped to the ip:port of the EJB nodes. For example,

Properties props = new Properties();
props.put("com.pramati.dns", "www.pramati.com");

com.pramati.force.standalone.ctx

Valid values are true and false. Forces Standalone contexts to be used. This is used when no load balancing and failover logic is required for the client. The default value is false.

com.pramati.naming.cacheLookups

Valid values are true and false. Enables and disables caching of looked up values. The default value is true.

com.pramati.naming.distributeLoad

Valid values are true and false. This is specifically for Pramati Cluster. For Java Clients, this property determines whether load balance is provided for every new InitialContext() call. The default value is false.

If this property is not set, all new InitialContext() calls go to the same EJB node in the Cluster. If set to true, every new InitialContext() call load-balances to a different EJB node in the Cluster.

The jndi.properties file consists of the following parameters:

If the Pramati Server name in specified, the parameters can be modified in three ways.

com.pramati.naming.cacheLookups

This parameter is common to standalone as well as clustered nodes. Default value is true.

The client context caches all looked up objects and improves performance as repeated lookups for the same object become faster due to caching. In a typical production environment, the value should be set to true for optimal performance. If the application is redeployed, lookup of a cached object would return a stale copy. It will throw an exception from the cache.

In a development environment, where performance is not the objective, this option can be set to false. The looked up object returned will always be the latest copy.

© Pramati Technologies 2007 Runs on Pramati Server | Feedback | Legal