[seam-dev] persistence module page drafted

[Dan Allen]

On Thu, Apr 15, 2010 at 3:15 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

>
> On 14 avr. 2010, at 20:21, Dan Allen wrote:
>
> On Wed, Apr 14, 2010 at 9:13 AM, Pete Muir <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?
>
>
> So your proposal was only describing what already exists here?
>
> http://docs.jboss.org/seam/2.2.1.CR1/api/org/jboss/seam/transaction/UserTransaction.html
>
> If yes then, that's fine. But frankly the wiki wording sounds like you are
> on your way to design a brand new API.
>

Doh! Time to fix it.


>
> So if the proposal is:
>  - create an extension of javax.transaction.UserTransaction to provide
> convenience methods
>  - use this interface as a wrapper around all the transaction apis out
> there (ie basically using javax.transaction.UserTransaction as the tx
> gateway for everyone - unit test up to JTA)
>  - provide implementations of these wrappers
>
> I'll update the wiki with these bullets.

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100416/10f09ac1/attachment-0001.html