You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@bea.com> on 2007/02/16 17:38:27 UTC
WebSphere and transaction managers
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.
Re: WebSphere and transaction managers
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <pl...@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 <pl...@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!
RE: WebSphere and transaction managers
Posted by Patrick Linskey <pl...@bea.com>.
> Does OpenJPA need to provide this level of support for
> all TM's? That's what I meant by my question.
I don't think that OpenJPA *needs* to, but it certainly will improve the
out-of-the-box experience for WAS users.
Are there any public WAS hooks that we can use to automatically deploy a
SLSB into a WAS environment during OpenJPA startup?
In any event, there's an easy workaround right now (use the internal WAS
methods, as outlined in the JIRA), and there will be another easy
workaround soon (use non-jta-data-source).
-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: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Monday, February 19, 2007 6:54 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: WebSphere and transaction managers
>
> Craig,
>
> On 2/19/07, Craig L Russell <Cr...@sun.com> wrote:
> >
> >
> > On Feb 19, 2007, at 4:37 PM, Kevin Sutter wrote:
> >
> > > On 2/19/07, Patrick Linskey <pl...@bea.com> wrote:
> > >>
> > >>
> > >> 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.
> > >
> > >
> > > Although this approach is probably workable, this sounds more
> > > complicated
> > > than just requiring the use of the non-jta-data-source element.
> > > WebSphere
> > > will eventually support the non-jta-data-source (supposedly in the
> > > next Beta
> > > of the EJB3 Feature Pack).
> >
> > This would be welcome news, indeed.
> >
> > > Wouldn't that be the preferred (and spec
> > > compliant) method of "nesting" transactions?
> >
> > I think so.
> > >
> > > I suppose since OpenJPA already supports this "suspension" via
> > > other TM's,
> > > is it our desire to support this mechanism for all TM's?
> >
> > I think so. Is WAS the only application server that doesn't support
> > non-JTA DataSource?
>
>
> Craig, I meant the ability to suspend a transaction. It
> seems that OpenJPA
> has provided for suspending of transactions via various API's (some
> external, some internal). So, it seems that some TM's allow
> for suspension
> of in-flight transactions, while others (like WAS) does not.
> At least not
> via public API's. Does OpenJPA need to provide this level of
> support for
> all TM's? That's what I meant by my question.
>
> Craig
> >
> > >
> > > Kevin
> > >
> > >
> > > On 2/19/07, Patrick Linskey <pl...@bea.com> 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.
> > >>
> > >> -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 <pl...@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 <pl...@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!
> >
> >
> >
>
Re: WebSphere and transaction managers
Posted by Kevin Sutter <kw...@gmail.com>.
Craig,
On 2/19/07, Craig L Russell <Cr...@sun.com> wrote:
>
>
> On Feb 19, 2007, at 4:37 PM, Kevin Sutter wrote:
>
> > On 2/19/07, Patrick Linskey <pl...@bea.com> wrote:
> >>
> >>
> >> 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.
> >
> >
> > Although this approach is probably workable, this sounds more
> > complicated
> > than just requiring the use of the non-jta-data-source element.
> > WebSphere
> > will eventually support the non-jta-data-source (supposedly in the
> > next Beta
> > of the EJB3 Feature Pack).
>
> This would be welcome news, indeed.
>
> > Wouldn't that be the preferred (and spec
> > compliant) method of "nesting" transactions?
>
> I think so.
> >
> > I suppose since OpenJPA already supports this "suspension" via
> > other TM's,
> > is it our desire to support this mechanism for all TM's?
>
> I think so. Is WAS the only application server that doesn't support
> non-JTA DataSource?
Craig, I meant the ability to suspend a transaction. It seems that OpenJPA
has provided for suspending of transactions via various API's (some
external, some internal). So, it seems that some TM's allow for suspension
of in-flight transactions, while others (like WAS) does not. At least not
via public API's. Does OpenJPA need to provide this level of support for
all TM's? That's what I meant by my question.
Craig
>
> >
> > Kevin
> >
> >
> > On 2/19/07, Patrick Linskey <pl...@bea.com> 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.
> >>
> >> -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 <pl...@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 <pl...@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!
>
>
>
Re: WebSphere and transaction managers
Posted by Craig L Russell <Cr...@Sun.COM>.
On Feb 19, 2007, at 4:37 PM, Kevin Sutter wrote:
> On 2/19/07, Patrick Linskey <pl...@bea.com> wrote:
>>
>>
>> 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.
>
>
> Although this approach is probably workable, this sounds more
> complicated
> than just requiring the use of the non-jta-data-source element.
> WebSphere
> will eventually support the non-jta-data-source (supposedly in the
> next Beta
> of the EJB3 Feature Pack).
This would be welcome news, indeed.
> Wouldn't that be the preferred (and spec
> compliant) method of "nesting" transactions?
I think so.
>
> I suppose since OpenJPA already supports this "suspension" via
> other TM's,
> is it our desire to support this mechanism for all TM's?
I think so. Is WAS the only application server that doesn't support
non-JTA DataSource?
Craig
>
> Kevin
>
>
> On 2/19/07, Patrick Linskey <pl...@bea.com> 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.
>>
>> -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 <pl...@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 <pl...@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!
Re: WebSphere and transaction managers
Posted by Kevin Sutter <kw...@gmail.com>.
On 2/19/07, Patrick Linskey <pl...@bea.com> wrote:
>
>
> 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.
Although this approach is probably workable, this sounds more complicated
than just requiring the use of the non-jta-data-source element. WebSphere
will eventually support the non-jta-data-source (supposedly in the next Beta
of the EJB3 Feature Pack). Wouldn't that be the preferred (and spec
compliant) method of "nesting" transactions?
I suppose since OpenJPA already supports this "suspension" via other TM's,
is it our desire to support this mechanism for all TM's?
Kevin
On 2/19/07, Patrick Linskey <pl...@bea.com> 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.
>
> -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 <pl...@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 <pl...@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!
> >
> >
>
RE: WebSphere and transaction managers
Posted by Patrick Linskey <pl...@bea.com>.
> > 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.
-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 <pl...@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 <pl...@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!
>
>
Re: WebSphere and transaction managers
Posted by Kevin Sutter <kw...@gmail.com>.
I understand. The concerns with the unmatched suspend/resume are known
within WebSphere circles quite well. I'm sure IBM was one of the voices
that objected to this functionality. :-)
I haven't had the time yet, but I want to understand the need for the
suspend/resume functionality within OpenJPA. In my mind, it shouldn't be
necessary. But, I haven't put a whole lot of thought into it yet...
Kevin
On 2/19/07, Craig L Russell <Cr...@sun.com> wrote:
>
> Hi Kevin,
>
> Actually, I'll recant. This would not be a hack, because it does
> guarantee that the suspension of the transaction is only for the
> duration of the method call. IIRC, when we were discussing the
> functionality of the TransactionSynchronizationRegistry, and
> considered adding useful features like "suspend" and "resume", there
> were objections that this might result in unmatched suspend/resume
> pairs, which would be a reasonable use case.
>
> The biggest downside to the proposal here is that it requires more
> setup in a server environment. The suspend/resume component would
> have to be deployed in each ear where it was needed, or deployed as a
> shared component (which is still not portable Java EE behavior IIRC).
>
> Craig
>
> On Feb 19, 2007, at 12:37 PM, Kevin Sutter wrote:
>
> > Excellent use of the Java EE features! :-)
> >
> > Kevin
> >
> > On 2/19/07, Craig L Russell <Cr...@sun.com> wrote:
> >>
> >> 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 <pl...@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 <pl...@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!
>
>
>
Re: WebSphere and transaction managers
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Kevin,
Actually, I'll recant. This would not be a hack, because it does
guarantee that the suspension of the transaction is only for the
duration of the method call. IIRC, when we were discussing the
functionality of the TransactionSynchronizationRegistry, and
considered adding useful features like "suspend" and "resume", there
were objections that this might result in unmatched suspend/resume
pairs, which would be a reasonable use case.
The biggest downside to the proposal here is that it requires more
setup in a server environment. The suspend/resume component would
have to be deployed in each ear where it was needed, or deployed as a
shared component (which is still not portable Java EE behavior IIRC).
Craig
On Feb 19, 2007, at 12:37 PM, Kevin Sutter wrote:
> Excellent use of the Java EE features! :-)
>
> Kevin
>
> On 2/19/07, Craig L Russell <Cr...@sun.com> wrote:
>>
>> 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 <pl...@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 <pl...@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!
Re: WebSphere and transaction managers
Posted by Kevin Sutter <kw...@gmail.com>.
Excellent use of the Java EE features! :-)
Kevin
On 2/19/07, Craig L Russell <Cr...@sun.com> wrote:
>
> 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 <pl...@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 <pl...@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!
>
>
>
Re: WebSphere and transaction managers
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <pl...@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 <pl...@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!
Re: WebSphere and transaction managers
Posted by Kevin Sutter <kw...@gmail.com>.
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 <pl...@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 <pl...@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.
> > >
> >
>
RE: WebSphere and transaction managers
Posted by Patrick Linskey <pl...@bea.com>.
>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 <pl...@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.
> >
>
Re: WebSphere and transaction managers
Posted by Albert Lee <al...@gmail.com>.
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 <pl...@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.
>