[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1144) Make org.jboss.seam.util.Transactions a seam component

Wed Apr 11 10:31:58 EDT 2007

    [ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12358946 ] 

Michael Youngstrom commented on JBSEAM-1144:
--------------------------------------------

I don't think you read what I said before.  This transaction component IMPLEMENTS UserTransaction and nothing else.  It does not provide a new Transaction interface.

"And it should be obvious that the "natural migration path" is _away_ from proprietary (Spring, org.hibernate.Transaction) and useless (javax.persistence.EntityTransaction) APIs _towards_ a standard API (javax.transaction.UserTransaction)."

I agree.  And I think this patch is a great avenue towards that migration path.  The seam component implements UserTransaction.  So the migration path is clear.  Provide a standard JTA/EJB implementation like we have and like what util.Transactions was doing but in a cleaner way.  Optionally provide other component implementations which expose EntityTransaction and org.hibernate.Transaction as UserTransaction instances.  You get everyone to migrate off of their resource local transaction interfaces and onto JTA's UserTransaction.  Then when JTA becomes more prevalent, is improved, or becomes easier to configure, etc. We simply remove the other transaction component implementations and everyone is now using standard JTA with the UserTransaction interface.  No interfaces to deprecate because everyone was using UserTransaction from the beginning.

One other thought, everything else in Seam is a component what makes JTA so different that it cannot be exposed as a component as well?  Making transaction management a component helps to clean up other things in seam too such as:

Being able to set a custom userTransactionName on the actual Transaction Component instead of using init and storing it in a static field.

Giving people the option to "turn off" transaction management in seam.  Maybe they have no need to hit a database.  Seam allows you to simply not install a component in a standard way.  Seam can now take advantage of that standard functionality in places like ExceptionFilter and TransactionInterceptor.  In the case of ExceptionFilter you can now have a clear and Seam standard way to determine if Seam is providing Transaction support or not.  If it is it can rollback the transaction if not it won't even try.  In the case of TransactionInterceptor you now have a simple standard way to determine if Transaction support is installed in Seam or not so you can now show the user a nice error message if they try to use Transaction support when it is not installed.

What can be wrong with exposing transactions in seam the same way everything else in Seam is exposed?  Without creating any new Interfaces and providing a clear migration path to JTA for those not currently using JTA?

Mike

> Make org.jboss.seam.util.Transactions a seam component
> ------------------------------------------------------
>
>                 Key: JBSEAM-1144
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-1144
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.2.1.GA
>            Reporter: Michael Youngstrom
>             Fix For: 1.3.0.BETA1
>
>         Attachments: seam-tx-2.zip, seam-tx.patch
>
>
> I know this is probably a loaded issue but please hear me out. :)  It would be nice if org.jboss.seam.util.Transactions was replaced with a Seam Component just like everything else in Seam.  This would allow for pluggable Transaction Management providers and pave the way for support for Spring Managed Transactions, JPA Local Transactions, and true Hibernate Local Transactions.  This will allow Seam applications to run without a dependency on microcontainer in tomcat and allow for tighter Framework integration with spring and others.
> I would personally be more than willing to do the work of making the an initial JTATransaction component(s) as a replacement for org.jboss.seam.util.Transactions and would also create a SpringTransaction component as a proof of concept for extending the Transaction component.
> One problem I can see off hand is we may have to interact with a transaction in some places where a Seam ApplicationContext is not available.  However, I wonder if confining Seam transactions to a seam call might help simplify matters anyway?  For example transaction cleanup could take place in the @Destroy of the transaction component instead of in the ExceptionFilter?
> Also, this wouldn't be looked at as a JTA replacement but rather a service abstraction.  Just like any other java webapp if you're using enterprise services such as EJBs or JCA JTA would be required.  if you're running on tomcat or some other simple web container a resource local transaction manager (Spring's abstraction, JPA's, or Hibernate's) can be used.
> I'm sure there are tons of other problems I'm not looking at but worst case scenario this issue would be a great place to document them and to refer rejected feature requests. (for example JBSEAM-1118)
> What do you think?
> Mike

-- 
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