Problem: EJBean, like any POJO, can have fields. We want the changes made to the fields to be rolled back if a transaction is rolled back.
1. Managed Resources
Managed Resource is one of the most important concepts in JEE. Managed Resource Factory is a factory that is governed by Container. Usually it means that Container: takes care of security, administrates, pools, integrates with transaction and provides easy access to Resources. Managed Resource is a resource, for instance a connection, produced by Managed Resource Factory. It is managed by Container. Usually it means that Container reuse resource, if properly used then guarantees synchronized access, can intercept invocations, listens for life cycle changes.
Usually patterns provide indirections and abstractions, invoker and invokee are separated. This pattern acts opposite, exposes feature that is internal by its nature. Persistence Contexts are internal features of any EJB. The aim is to externalize it, to make it remote, a part of distributed environment.
This pattern was presented in Adam Bien’s Real World Java EE Patterns – Rethinking Best Practices and contributions belong to the author. The name Gateway comes from this publication.
- Bean performs operations on transactional Resource, for instance database connection, and on non-transactional Resource, for instance LDAP connection
- Bean exposes a business method that uses both database connection and LDAP connection
- Operations on database connection and LDAP connection must both succeed or be rolled back
What is the bast way to achieve it?
Stateful Session Beans are the least use type of EJBs. I saw a few usages of Stateful Session Beans but most of them were improper. Stateful Session Beans are the least understood type of EJBs. What are they for? Or better: show me use cases where Stateful Session Beans are essential solution! The internet gives several answers but not always proper. We will investigate those answers.
Singleton is the only type of Session Beans that admits concurrent access. This way bottlenecks are avoided. There are two manners of synchronizing access, bean synchronization and container synchronization. Default is container managed synchronization. We spare a few words on container managed synchronization.
- An application need to read configurations from an external source, for instance a file
- A configuration file might be changed during an application’s work
If EJB instance, other than Singleton, throws system exception, which is non application runtime exception, then EJB Container immediately discards the instance without calling @PreDestroy method.
This is not a problem if calling @PreDestroy is not essential to an application. If it is, then it was proposed to provide additional application pool of resources or beans and periodically clean up abandoned resources or beans. We do it other way.
- Application need to access Non-Managed Resource, for instance a plain TCP Connection
- Resources are heavily used
- To producing Resource, for instance to establish a TCP Connection and application-specific initialization, is time consuming
- Operations on Resources are stateless and nontransactional
Local EJB can be accessed by clients from the same application. But not only. The EJB specification admits that a local EJB can be accessed by any client from the same JVM. It is up to EJB Container provider if it allows such invocations. Fragment of EJB 3.1 specification: