[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1365) Make SeamManagedEntityManagerFactory joinTransaction if available

[Michael Youngstrom (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBSEAM-1365?page=comments#action_12363568 ] 
            
Michael Youngstrom commented on JBSEAM-1365:
--------------------------------------------

> EntityManager.joinTransaction() only works if you have a JTA transactionmanager available in JNDI.

Well, this isn't true because I'm doing this with a standalone JTA provider and it works fine.  There are a number of reasons why a project might choose a standalone JTA provider.  One reason might be the ability to propogate webservice transactions betweens many different application server types.  Maybe an application has a requirement to be hightly cross application server compatible and so the developers made a choice to integrate a standalone transaction manager to lower the risk of dealing with the quarks other platforms transaction managers might have and to provide a transaction manager for their app deployed in Tomcat or Jetty.

Atomikos, for example,  provides it's own Hibernate TransactionManagerLookup that enables joinTransaction() to work just fine without JNDI.

> There is no other scenario in which it is sensible.

You may have a point there.  True it is possible to integrate a thirdparty transaction manager into an application servers JNDI service but doing so can be a pain since JNDI isn't the most simple service to work with and extend.  It's one thing to integrate a standalone JTA service with a platform like Tomcat or Jetty with a readonly provider.  It's quite another to integrate a standalone JTA service with JNDI on a platform like Websphere with an existing JTA provider.  Potentially making it very difficult for a cross platform app to be deployed to many different app servers.


I can see how Seam for the sake of consistency and the goal of using what already exists might want to mandate all apps that use Seam must use JTA through JNDI and that's fine.  Although Seam provides this great component framework with the idea of making components extensible, replaceable, and removable why place this restriction on all Transaction components in the system that they must obtain a JTA transaction through JNDI?

So I see the choices for this issue as:

1. Let ManagedPersistenceContext.getEntityManager() attempt to detect if there is an active transaction outside the confines of any Seam Transaction component before joining?

2. Simply not attempt to automatically join a transaction if there is no Seam transaction component installed and let the app developer deal with it?

3. Do we let the JPA provider itself determine if it can join a current Transaction by calling joinTransaction and ?

I personally think 2 or 3 would be better than 1 but whatever the decision I can that this issue is fairly tightly joined with JBSEAM-1144.

So for right now do you want me to rollback the joinTransaction I'm doing in the Spring integration until we later sort out JBSEAM-1144 and this issue?

Mike

> Make SeamManagedEntityManagerFactory joinTransaction if available
> -----------------------------------------------------------------
>
>                 Key: JBSEAM-1365
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-1365
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Spring
>    Affects Versions: 1.2.1.GA
>            Reporter: Michael Youngstrom
>         Assigned To: Michael Youngstrom
>             Fix For: 1.3.0.ALPHA
>
>
> Spring correctly assumes that if EMF.createEntityManager is called while in a transaction that the newly created EntityManager will be joined in with the current transaction.  However, in the Seam Spring Integration, when Spring calls EMF.createEntityManager we might return an existing conversation scoped EM instead of a newly created one.  In which case we need to join the current transaction if there is one since spring will not.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira