[
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