[seam-dev] Persistence Module Overview

[Stuart Douglas]

I just though I would send out a quick overview of exactly what is in
the persistence module at the moment:


Transactions:

It provides a SeamUserTransaction object that extends the JTA
UserTransaction (this means a dependency on the jta API).

Three default implementations will be provided
- The default EE version that either looks up UserTransaction in JNDI
or retrieves it from the EJBContext if a CMT is active
- An implementation that uses EntityTransaction, this is retrieved from the SMPC
- An implementation that uses hibernate's transaction API (to be done)

It does not use the CDI's ability to inject the UserTransaction for a
number of reason:
- It is not available in all environments
- It is not available in EJB's that use CMT

It provides a transaction interceptor, this allows you to use
@TransactionAttribute on managed beans the same way you would on
EJB's.
It provides @Transactional and @SeamApplicationException for
environments where these API's are not available.

Managed Persistence Contexts

- Defined as follows:

@SeamManaged
@Produces
@ConversationScoped
@PersistenceUnit("myPu")
EntityManagerFactory enf;

- This will work even in environments where @PersistenceUnit injection
is not directly supported, as seam-persistence will bootstrap it for
you.

- The SMPC provides the following:
- Automatic transaction enlistment
- Ability to use EL in queries
- Automatic hibernate search integration, if available
- Ability to set manual flush mode if required
- Event is fired when the SMPC is created, to allow for additional
configuration such as adding hibernate filters.

It also provides @TransactionScoped for transaction scoped beans
(forgot to put this in the reference guide, oops)

There are currently tests for jboss-as, jetty, and jetty+openjpa (with
no hibernate classes present on the classpath). I am planning on also
adding glassfish, glassfish+hibernate, and probably a few more as
well.

I have also added seam managed transactions to the faces module, this
is similar to seam 2, however it has two notable improvements:
- It can be controlled on per view basis (including using wildcards)
- it can be enabled only for the RENDER_RESPONSE, so you have manual
transaction control in your business logic, and then seam opens a
transaction for you when rendering to prevent LIE's (this also can be
configured on a per view basis).

I think that just about covers it. If anyone has any questions or
comments fire away.

Stuart