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.
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?
- 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