How do beans manage resource connections to back-end services other than databases ?
Created May 4, 2012
Leveraging the instance fields:
This strategy works in stateless session beans and entity beans in EJB servers that pool and reuse these bean types. In stateless beans you can simply reference the resources using the instance fields -- stateless beans are not passivated in EJB. In entity beans you can also reference the connections using instance fields but the field used must not be declared as a container-managed field in the deployment descriptor.
In both stateless and entity beans there are methods can be used safely to open and close resource connections at the beginning and end of the beans life.
In stateless session beans long-lived resources should be opened in the
In entity beans long-lived resource should be opened in the
CORBA or Java RMI Services:
In stateful session beans the references will need to be released and re-constituted when the bean is activated using some kind of naming facility native to the reference type.
With stateless and entity beans the above strategy, Leveraging the instance fields works well with this strategy.
JNDI references:
Wait for EJB 2.0:
Each EJB vendor implements resource management differently. In EJB servers where the instance is pooled and reused it may be possible to allow a back-end resource connection to be maintained through passivation. The back-end connection might wrapped in a CORBA or Java RMI object, accessed by a raw network socket, or some other connection facility.
setSessionContext( )
method and closed in the ejbRemove( )
method. These methods are invoked at the beginning and end of a stateless session instance's life; when it's first instantiated and before its evicted form the container.
setEntityContext( )
method and closed in the unsetEntityContext( )
method. These methods are invoked at the beginning and end of an entity instance's life; when it's first instantiated and before its evicted form the container.
CORBA objects or Java RMI objects can be created that wrapper usual resources and expose them to the bean. These types of remote references will need to be handled with care as they can be affected by passivation, but the remote objects themselves are not part an EJB container and therefor are not passivated.
It may be possible to access a JNDI service directly from the bean and to attach live resources to the JNDI service. This depends on the JNDI service provider and your EJB vendor.
The next version of EJB, which may be branded EJB 2.0, is supposed to include a Connection specification that details how connections to non-standard resources can be make available to beans at run time. If this is done correctly it will solve this problem, but who knows when or if it will be incorporated into the specification. Don't hold your breath.