Re: WebSphere and transaction managers

[Craig L Russell]

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.

the container take care of demarcation. Certainly an interesting
approach for providing similar ease-of-use in a WebSphere environment.


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.

Interesting. We could even mark the method as @RequiresNew, thus letting Maybe we should add a method to our ManagedRuntime interface to accept a

Craig

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?

-Patrick

--
Patrick Linskey
BEA Systems, Inc.


by email and then delete it.

______________________________________________________________________ _ 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

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

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

smime.p7s
Description: S/MIME cryptographic signature