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.
For example. A Data Source provides access to database. If configured by a server then it is Managed Resource Factory. A Data Source wraps JDBC which is Resource Factory. JDBC produces database connections which are called physical database connections. A Data Source asked for a connection does not return physical connection as it is, but wraps it. Wrapper implements Connection interface and simulates regular connection. Wrapper is called logical connection.
Physical connection life cycle:
- Container creates new connection when a pool is empty, and new connection is needed.
- A connection is in a pool of free connections.
- A component ask for a connection, a connection is taken from a pool, wrapped with logical connection and returned.
- A component invokes close, logical connection intercepts invocation, physical connection is not closed, rather returned to a pool, we go back to point 2.
- Container closes excessive and idle connections from a pool.
2. Shared Resources
Managed Resource can be Shared or UnShared. This is a component level configuration. By default Managed Resources are Shared. UnShared setting is not recommended unless you know what are you doing.
Shared setting bounds Managed Resource to a transaction.
- A transaction is started.
- First component obtains Managed Resource from Container.
- Any other component asks for Managed Resource from the same Managed Resource Factory. Obtained Managed Resource represents the same resource as first component used. I.e. if first component got a database connection and other component got a database connection within the same transaction then this is the same database connection, in particular modification made by first component are visible in other components.
- A transaction is committed. Bounded Managed Resources are committed and released.
3. Diamond Problem
Diamond Problem refers to situation when multiple clients communicates with a server within a single global transaction. The server should detect that situation and treat all clients as one. I.e. modifications made by one client are visible by other client before commit occur. We say that the server supports or resolves Diamond Problem.
Diamond Problem is very tough and difficult to resolve. It is important for databases because they are responsible for data consistency. We can distinguish databases that support or do not support global transactions. Databases supporting global transactions can be further distinguished as supporting Diamond Problem and not supporting. Allowing multiple clients to connect to a database within a single global transaction can decrease performance.
It is easy to check if a database supports Diamond Problem: just use a single transactional client with an isolated transaction, let it open two physical connections and check if modifications make with one connections are visible with other. The database cannot know that two separate connections come from the same client, from the database view two connections represents two clients.
4. Nontransactional EJB
EJB Container is not obligated to support Diamond Problem i.e. it is not obligated to recognize clients by transactions. And you should not assume it. Actually there is no such need. For two reasons:
- EJBeans are not transactional i.e. they support global transactions but their state is not transactional. They support global transactions on resource level, just propagate transactions to resources, Managed Resources. But if change is made to EJBean state, the state is not rolled back in case of transaction roll back. Moreover, there is no guarantee that the Stateless Session Bean instance is exclusively locked during transaction. The bean instance accessed by one client, can be accessed by another client with another transaction even when the previous transaction has not end yet. Thus on bean level transactions are meaningless.
- Managed Resource’s Shared setting works internally inside a single JVM. Container resolves Diamond Problem locally, but not for remote clients. When two remote clients within a single global transaction sequentially access EJB Container and invoke business methods and each method access a database then different business methods use different physical connections. Even within demarcation of the same transaction. But it is not a problem because we can expect that the database resolve Diamond Problem. Moreover, EJB Container does not allow to use Managed Resource by a transaction if the previous transaction is active. Thus on resource level transactions are meaningful but Diamond Problem is resolved further by a database.