openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Lee" <allee8...@gmail.com>
Subject Re: WebSphere and transaction managers
Date Fri, 16 Feb 2007 19:20:41 GMT
This is known problem in WAS. The reason is data source created in WAS is
always enlisted in the current global transaction, therefore RESOURCE_LOCAL
persistence unit using WAS data source triggers the observed behavior.

This limitation will be corrected in the WAS EJB3 Feature Pack and future
releases.

Immediate solution is not to specify the non-jta-data-source in the
persistence unit but replace with connection information using properties
  openjpa.ConnectionUserName
  openjpa.ConnectionPassword
  openjpa.ConnectionURL
  openjpa.ConnectionDriverName

It is not the ideal solution, but functional.

Albert Lee

On 2/16/07, Patrick Linskey <plinskey@bea.com> wrote:
>
> Hi,
>
> It looks like the new WebSphere transaction manager lookup code is
> missing some functionality available elsewhere.
>
> See OPENJPA-149 (https://issues.apache.org/jira/browse/OPENJPA-149) and
> OPENJPA-153 (https://issues.apache.org/jira/browse/OPENJPA-153) for
> details.
>
> The key problems are:
>
> OPENJPA-149: the WASManagedRuntime class throws exceptions on some
> methods, preventing OpenJPA from being able to suspend transactions
>
> OPENJPA-153: even when specifying a non-JTA data source, the data source
> returned does not allow commits. It does seem like the behavior of the
> data source is at least a bit different than the JTA data source, since
> OpenJPA is able to call setAutoCommit().
>
> These seem like usability issues with WAS. I'm hoping that someone with
> more WAS knowledge than me can resolve the issues easily. Any takers?
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message