[seam-dev] persistence module page drafted

[Shane Bryzak]

Another option is for the transaction utility class to provide the 
convenience methods without extending UserTransaction, i.e like this:

public boolean isActive(UserTransaction transaction) {
   return transaction.getStatus() == STATUS.ACTIVE;
}


On 15/04/10 04:21, Dan Allen wrote:
> On Wed, Apr 14, 2010 at 9:13 AM, Pete Muir <pmuir at redhat.com 
> <mailto:pmuir at redhat.com>> wrote:
>
>     I'm with Emmanuel here.
>
>     All of this is addressable through an Transactions utiltiy class.
>
> Let me ask for two clarifications that will help me understand the 
> counter argument.
>
> 1. If this transaction wrapper extends UserTransaction, is that 
> worse/different than having a utility class? You can always inject the 
> native type, or inject the wrapper for the extra convenient status 
> methods.
> 2. The transaction wrapper allows us reuse the UserTransaction API to 
> address JTA, resource-local and potentially spring transaction APIs as 
> one. The client then doesn't concern itself with which transaction API 
> is being used under the covers, but everyone "speaks" JTA 
> UserTransaction. How do we do that with just a utility class?
>
> -Dan
> -- 
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100415/e4743795/attachment-0001.html