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

[Michael Youngstrom (JIRA)]

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

An email discussion with Gavin about this issue:

----------------------Gavin--------------------
Yes, I agree that in principle the UserTransaction (and perhaps even the
EJBContext) should be available as a Seam component. This feels more
seam-ish.

I looked briefly at your implementation, and I'm confused why you use
implementation of the interface and delegation instead of just using the
"manager component" pattern (ie. @Unwrap).

Have you thoroughly tested this to make sure that there were no places
where the old Transactions class was being called outside of a set of
Seam contexts (eg. in the cleanup cycle of the exception filter)?


-------------------Mike Youngstrom------------------

>I'm confused why you use implementation of the interface and
>delegation instead of just >using the "manager component" pattern (ie.
>@Unwrap).

I actually do @Unwrap to a UserTransaction instance however I don't
unwrap to the raw UserTransaction because one of my goals here was to
remove as much of the logic from util.Transactions as possible.  Part
of that logic was the pseudo combining of UserTransaction and
EJBContext.  To move that logic into the component I created a
UserTransaction instance that attempts to combine operations on
UserTransaction and EJBContext similar to what util.Transaction was
doing.

For example, if a user calls userTransaction.setRollbackOnly()
setRollbackOnly() will first be called on the delegate UserTransaction
if it is available and second on the current EJBContext if that is
available similar to what util.Transaction did before.  That way other
components don't need to worry about managing both UserTransaction and
EJBContext transactions.

If you don't like that idea that's fine I can move that logic back
into util.Transaction

> Have you thoroughly tested this to make sure that there were no places
> where the old Transactions class was being called outside of a set of
> Seam contexts (eg. in the cleanup cycle of the exception filter)?

The only instances I found of accessing a Transaction outside of the
seam lifecycle was the ExceptionFilter and the SeamPhaseListener.

In ExceptionFilter I actually changed the way it works a bit.  Before
if an exception was thrown but the exception didn't make to down to
the filter for whatever reason the current transaction was rolledback
and that was it.  I changed it so that if the seam contexts are not
cleaned up after doFilter then I attempt to rollback the transaction
and cleanup the threadlocals.  I have a copy of the new
ExceptionFilter in the seam-tx-3.zip.

In SeamPhaseListener I just moved the call to
handleTransactionsBeforePhase to after SeamPhaseListener calls
Lifecycle.beginRequest().

>From my testing and analysis everything appears to work as good as it
ever did but things seem a little cleaner now.

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