[seam-dev] Transactions and persistence

Pete Muir pmuir at redhat.com
Sat Jul 17 08:52:39 EDT 2010


On 17 Jul 2010, at 03:03, Stuart Douglas wrote:

> As some of you may know I've started looking at the transactions and persistence module. To start with I am just going to port what we had in seam 2, and we can work form there. I have already ported the UserTransaction wrapper stuff and the transaction interceptor. Alternate UserTransaction wrappers can be specified in seam XML (e.g. if you want to use HibernateTransaction).

Sounds good.

> 
> I have changed the default to use EJB synchronisations (<transaction:ejb-transaction/> from seam 2), you will need to manually install SeSynchronisations in a non EJB environment.  I will look at making the extension smart enough to detect this in most cases, so it will just work either way. 

Sounds good.

>  
> I think that in a normal EE6 setup this module should not require a single line of XML, configuration should only be required if you are in a non-EE environment. 

Agreed.

> 
> I that the SMPC should be configured with an annotation on a producer field, something like:
> 
> @Produces
> @ManagedPersistenceContext
> @PersistenceContext
> @ConversationScoped
> EntityManager entityManager;
> 
> I don't think we should override the behaviour of every resource producer field by default,

I disagree. This will require people to alter this code to move between EE and SE.

I'm not sure why you wouldn't want to do it automatically, assuming that the container can't handle @PersistenceContext itself.

> and xml configuration should also be supported. 

Sure, but we get this for free :-)

> 
> Questions:
> 
> Do we want to allow @TransactionAttribute to be used on managed beans (as well as @Transactional)?

I think this seems reasonable. We probably want to use our own version of it though.

> 
> I think we should do this. Also there was talk of changing the names used in the seam provided annotation, is that still on the cards (personally I am very much against this)? 

No, we aren't doing this.

> 
> Are we still going to provide seam equivalents of the EE API's (e.g. @ApplicationException etc)? 
> 
> I'm guessing yes.

I think yes.

> 
> Seam 2 allowed you to use seam-jndi.properties to specify JNDI properties
> 
> Are we going to do something like this? If so where at. 

Sounds like we can just copy the approach Seam 2 had - not aware of problems with it.

> 
> Are we going to support REQUIRES_NEW for managed beans?
> 
> I really want this. It will probably only be availible in a JTA environment though, and will probably require XML configuration in some cases.
> 
> Are we going to stop the ManagedPersistenceContext from propagating across the transaction boundary for REQUIRES_NEW transactions?
> 
> I think that in this situation:
> 
> @Stateless
> public class MyEJB
> {
>   @Inject EntityManager entityManager;
> 
>   @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
>   public void doStuff()
>   {
> 	entityManager.createQuery(...);
>        ...	
>   }
> }
> 
> we should inject a new EM rather than one that is enlisted in the outside transaction. We could also provide a TransactionScoped em, but that does not solve the problem in the following situation:
> 
> @Stateless
> public class MyEJB
> {
>   @Inject HelperBean helper;
> 
>   @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
>   public void doStuff()
>   {
> 	helper.doStuff()
>   }
> }
> 
> public class HelperBean {
> 
>   @Inject EntityManager entityManager;
>   public void doStuff() {};
> }
> 
> I think that we should maintain a stack of EM's in the Managed Persistence Context, and push a new one when we cross a transaction boundary, so all em calls after than point are invoked on a new EM. This is a real problem, and there are heaps of posts about this in the seam 2 forum.

Personally, I'm leaning towards not supporting it - if people need this, they should use the EJB Embeddable container.

> 
> Where do seam managed transactions belong?
> 
> Probably the faces module. 

Yes, and I think they are already there (or planned)

> 
> Do we want to support multiple RESOURCE_LOCAL transactions?
> 
> There have been quite a few posts on the forum about this, but I don't know if it really makes sense. You would need some way of telling the transaction interceptor which UT it is supposed to use. Seam managed transaction would probably have to work on both transactions, wether they are needed or not. 

Again, I don't think this is needed, you just have to use the EJB Embeddable container.


More information about the seam-dev mailing list