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.