EJB with transactional state

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.

The Diamond Problem

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.

Advertisement

Gateway

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.

Using transactional and non-transactional Resources simultaneously

Problem:

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

Improper uses of Stateful Session Beans

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 Locks

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.

Configuration Reader

Problem:

• 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

Missed PreDestroy calls

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.

Non Managed Resources (1)

Problem:

• 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

Cross-application local bean invocations

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: