openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: WebSphere and transaction managers
Date Mon, 19 Feb 2007 23:54:37 GMT

On Feb 19, 2007, at 3:06 PM, Patrick Linskey wrote:

>>> I would have to better understand OpenJPA's need for the transaction
>>> suspension before determining whether there are alternatives
>>> available.
>
> The use case is that if we can suspend the tx, then the user doesn't
> need to provide a non-JTA data source.
>
>> The idea is to create an EJB component solely for the purpose of
>> suspending a transaction. This could be a Stateless Session
>> Bean that defines a method declared as Transaction Not Supported.
>
> Interesting. We could even mark the method as @RequiresNew, thus  
> letting
> the container take care of demarcation. Certainly an interesting
> approach for providing similar ease-of-use in a WebSphere environment.
>
> Maybe we should add a method to our ManagedRuntime interface to  
> accept a
> Runnable that should be run in a separate transaction, and migrate our
> code to use that approach.
> That way, the WASManagedRuntime could do what
> Craig outlined, and other ManagedRuntime impls could retain their
> current behavior.

So what is the WAS approach for deployment of a shared EJB SSB? Is  
there a concept that can be used when installing OpenJPA once, or  
does each ear that needs this functionality required to deploy the SSB?

Craig
>
> -Patrick
>
> -- 
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________________ 
> _
> Notice:  This email message, together with any attachments, may  
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted   
> and/or
> legally privileged, and is intended solely for the use of the  
> individual
> or entity named in this message. If you are not the intended  
> recipient,
> and have received this message in error, please immediately return  
> this
> by email and then delete it.
>
>> -----Original Message-----
>> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>> Sent: Monday, February 19, 2007 8:33 AM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Re: WebSphere and transaction managers
>>
>> It is possible to suspend a transaction by the standard Java EE
>> technique. Unfortunately, this might be considered a hack, but AFAIK
>> it's perfectly legal.
>>
>> The idea is to create an EJB component solely for the purpose of
>> suspending a transaction. This could be a Stateless Session
>> Bean that
>> defines a method declared as Transaction Not Supported. The method
>> invocation would contain a runnable as an argument which the
>> execution of the method would then run. Once the runnable completed,
>> returning from the method would resume the suspended transaction. If
>> needed, an Object returned from the method could contain the results
>> of the method.
>>
>> Craig
>>
>> On Feb 19, 2007, at 8:14 AM, Kevin Sutter wrote:
>>
>>> The WebSphere Transaction API does not allow for suspension of a
>>> transaction.  Even if we move to the "official" JPA transaction API
>>> (TransactionSynchronizationRegistry), there is no suspend method
>>> available.
>>> I would have to better understand OpenJPA's need for the transaction
>>> suspension before determining whether there are alternatives
>>> available.
>>>
>>> On 2/16/07, Patrick Linskey <plinskey@bea.com> wrote:
>>>>
>>>> From what the user said, it sounds like another solution
>> is to use a
>>>> different ManagedRuntime that allows suspension. My guess is that
>>>> this
>>>> is not an "official" IBM API, and is the reason that we're not
>>>> using it.
>>>> Is there some other official means by which we could change
>>>> WASManagedRuntime to allow suspend etc.?
>>>>
>>>> In short, if we solve OPENJPA-149, then we have the easiest-of-all
>>>> pathways covered, and OPENJPA-153 is less important.
>>>>
>>>> -Patrick
>>>>
>>>> --
>>>> Patrick Linskey
>>>> BEA Systems, Inc.
>>>>
>>>>
>> _____________________________________________________________________
>>>> __
>>>> Notice:  This email message, together with any attachments, may
>>>> contain
>>>> information  of  BEA Systems,  Inc.,  its subsidiaries  and
>>>> affiliated
>>>> entities,  that may be confidential,  proprietary,  copyrighted
>>>> and/or
>>>> legally privileged, and is intended solely for the use of the
>>>> individual
>>>> or entity named in this message. If you are not the intended
>>>> recipient,
>>>> and have received this message in error, please
>> immediately return
>>>> this
>>>> by email and then delete it.
>>>>
>>>>> -----Original Message-----
>>>>> From: Albert Lee [mailto:allee8285@gmail.com]
>>>>> Sent: Friday, February 16, 2007 11:21 AM
>>>>> To: open-jpa-dev@incubator.apache.org
>>>>> Subject: Re: WebSphere and transaction managers
>>>>>
>>>>> This is known problem in WAS. The reason is data source
>>>>> created in WAS is
>>>>> always enlisted in the current global transaction, therefore
>>>>> RESOURCE_LOCAL
>>>>> persistence unit using WAS data source triggers the observed
>>>> behavior.
>>>>>
>>>>> This limitation will be corrected in the WAS EJB3 Feature
>>>>> Pack and future
>>>>> releases.
>>>>>
>>>>> Immediate solution is not to specify the
>> non-jta-data-source in the
>>>>> persistence unit but replace with connection information
>>>>> using properties
>>>>>   openjpa.ConnectionUserName
>>>>>   openjpa.ConnectionPassword
>>>>>   openjpa.ConnectionURL
>>>>>   openjpa.ConnectionDriverName
>>>>>
>>>>> It is not the ideal solution, but functional.
>>>>>
>>>>> Albert Lee
>>>>>
>>>>> On 2/16/07, Patrick Linskey <plinskey@bea.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It looks like the new WebSphere transaction manager lookup
>>>> code is
>>>>>> missing some functionality available elsewhere.
>>>>>>
>>>>>> See OPENJPA-149
>>>>> (https://issues.apache.org/jira/browse/OPENJPA-149) and
>>>>>> OPENJPA-153 (https://issues.apache.org/jira/browse/
>>>> OPENJPA-153) for
>>>>>> details.
>>>>>>
>>>>>> The key problems are:
>>>>>>
>>>>>> OPENJPA-149: the WASManagedRuntime class throws exceptions on
>>>> some
>>>>>> methods, preventing OpenJPA from being able to suspend
>>>> transactions
>>>>>>
>>>>>> OPENJPA-153: even when specifying a non-JTA data source,
>>>>> the data source
>>>>>> returned does not allow commits. It does seem like the
>>>>> behavior of the
>>>>>> data source is at least a bit different than the JTA data
>>>>> source, since
>>>>>> OpenJPA is able to call setAutoCommit().
>>>>>>
>>>>>> These seem like usability issues with WAS. I'm hoping that
>>>>> someone with
>>>>>> more WAS knowledge than me can resolve the issues easily.
>>>>> Any takers?
>>>>>>
>>>>>> -Patrick
>>>>>>
>>>>>> --
>>>>>> Patrick Linskey
>>>>>> BEA Systems, Inc.
>>>>>>
>>>>>>
>>>>> ______________________________________________________________
>>>>> _________
>>>>>> Notice:  This email message, together with any attachments,
>>>>> may contain
>>>>>> information  of  BEA Systems,  Inc.,  its subsidiaries  and
>>>>>  affiliated
>>>>>> entities,  that may be confidential,  proprietary,
>>>>> copyrighted  and/or
>>>>>> legally privileged, and is intended solely for the use of
>>>>> the individual
>>>>>> or entity named in this message. If you are not the
>>>>> intended recipient,
>>>>>> and have received this message in error, please immediately
>>>>> return this
>>>>>> by email and then delete it.
>>>>>>
>>>>>
>>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message