OPENJPA-149

[Michael Dick <mi...@gmail.com>]

I've been looking at this issue and OPENJPA-159 in my "copious" free time.
The official supported way to  submit work outside of a transaction in
WebSphere is to go through a WebSphere proprietary interface (similar to
what we have in WASManagedRuntime).

Unfortunately that interface is not published in any maven repository, or
generally made available in a central location. We were able to get
permission to use a precompiled jar for our build process, but we can't
redistribute it (ie publish it to a maven repository). It can be included in
our source repository though. I believe this approach is used by other
vendors who use the APIs (ie Spring if I'm not mistaken).

The net outcome is that we have two options:

1. Use the proprietary interfaces in the same manner as we do in
WASManagedRuntime - use serp to add an interface to one of our classes (not
an entity) after we've compiled it. When the class is used we'll use
reflection to invoke the appropriate methods.

2. Add the WebSphere jar in our svn repository and then reference it as a
system dependency (won't be shipped as a dependency) in the maven build .
The class(es) that use the proprietary interfaces can call methods directly
and we can avoid the bytecode weaving. The downside is there will be a 4.7 K
jar file added to svn. It's relatively light weight and it shouldn't be
changed often (if at all).

How to people feel about including the WebSphere APIs in this way? On the
one hand it make the code quite a bit easier to maintain, but on the other
hand it's a binary in SVN.

-Mike

Re: OPENJPA-149

[Michael Dick <mi...@gmail.com>]

Essentially that's the case. OpenJPA-159 is the JIRA that deals with
creating a doNonTransactionalWork(Runnable r) method on the ManagedRuntime
classes. When that's committed a GeronimoManagedRuntime class could be
written that does whatever needs to be done for Geronimo. Similarly the
existing ManagedRuntimes for WebLogic / SunOne / <insert your favorite app
server here> could be updated to take advantage of the new interface.

OpenJPA-149 is specific to WebSphere and will add a ManagedRuntime that can
handle WebSphere's tweaks. In this case it's not quite as simple as just
calling a methods via reflection.

In order to do the non transactional work in WebSphere we need to provide a
class which implements a proprietary interface. It's rather tricky to do so
when we can't compile against the interface though. We solved a similar
problem for previous releases by using bytecode weaving to add an interface
to a class after we compiled it. The same approach will work, but it's
counter intuitive. We received the appropriate legal clearance from
WebSphere to use their compiled classes, but I wanted to make sure adding
them to SVN was "kosher" before I commit them.

-Mike

On Wed, Apr 16, 2008 at 8:32 PM, David Jencks <da...@yahoo.com>
wrote:

> IIUC this is the interface that abstracts the "requiresNew" tx policy into
> a single method on the tm?
>
> Personally I'd like openjpa to define such an interface and use it no
> matter what the environment.  Then perhaps the websphere adapter code can
> call the WAS interface/class using reflection?
>
> I've been having big problems with openjpa in geronimo unless I supply
> both the jta and non-jta datasources.  I have some hope that if I can
>  implement such a "doInNewTx" method I'll be able to solve these problems.
>
> thanks
> david jencks
>
>
> On Apr 16, 2008, at 1:03 PM, Michael Dick wrote:
>
>  I've been looking at this issue and OPENJPA-159 in my "copious" free
> > time.
> > The official supported way to  submit work outside of a transaction in
> > WebSphere is to go through a WebSphere proprietary interface (similar to
> > what we have in WASManagedRuntime).
> >
> > Unfortunately that interface is not published in any maven repository,
> > or
> > generally made available in a central location. We were able to get
> > permission to use a precompiled jar for our build process, but we can't
> > redistribute it (ie publish it to a maven repository). It can be
> > included in
> > our source repository though. I believe this approach is used by other
> > vendors who use the APIs (ie Spring if I'm not mistaken).
> >
> > The net outcome is that we have two options:
> >
> > 1. Use the proprietary interfaces in the same manner as we do in
> > WASManagedRuntime - use serp to add an interface to one of our classes
> > (not
> > an entity) after we've compiled it. When the class is used we'll use
> > reflection to invoke the appropriate methods.
> >
> > 2. Add the WebSphere jar in our svn repository and then reference it as
> > a
> > system dependency (won't be shipped as a dependency) in the maven build
> > .
> > The class(es) that use the proprietary interfaces can call methods
> > directly
> > and we can avoid the bytecode weaving. The downside is there will be a
> > 4.7 K
> > jar file added to svn. It's relatively light weight and it shouldn't be
> > changed often (if at all).
> >
> > How to people feel about including the WebSphere APIs in this way? On
> > the
> > one hand it make the code quite a bit easier to maintain, but on the
> > other
> > hand it's a binary in SVN.
> >
> > -Mike
> >
>
>

Re: OPENJPA-149

[David Jencks <da...@yahoo.com>]

IIUC this is the interface that abstracts the "requiresNew" tx policy  
into a single method on the tm?

Personally I'd like openjpa to define such an interface and use it no  
matter what the environment.  Then perhaps the websphere adapter code  
can call the WAS interface/class using reflection?

I've been having big problems with openjpa in geronimo unless I  
supply both the jta and non-jta datasources.  I have some hope that  
if I can  implement such a "doInNewTx" method I'll be able to solve  
these problems.

thanks
david jencks

On Apr 16, 2008, at 1:03 PM, Michael Dick wrote:

> I've been looking at this issue and OPENJPA-159 in my "copious"  
> free time.
> The official supported way to  submit work outside of a transaction in
> WebSphere is to go through a WebSphere proprietary interface  
> (similar to
> what we have in WASManagedRuntime).
>
> Unfortunately that interface is not published in any maven  
> repository, or
> generally made available in a central location. We were able to get
> permission to use a precompiled jar for our build process, but we  
> can't
> redistribute it (ie publish it to a maven repository). It can be  
> included in
> our source repository though. I believe this approach is used by other
> vendors who use the APIs (ie Spring if I'm not mistaken).
>
> The net outcome is that we have two options:
>
> 1. Use the proprietary interfaces in the same manner as we do in
> WASManagedRuntime - use serp to add an interface to one of our  
> classes (not
> an entity) after we've compiled it. When the class is used we'll use
> reflection to invoke the appropriate methods.
>
> 2. Add the WebSphere jar in our svn repository and then reference  
> it as a
> system dependency (won't be shipped as a dependency) in the maven  
> build .
> The class(es) that use the proprietary interfaces can call methods  
> directly
> and we can avoid the bytecode weaving. The downside is there will  
> be a 4.7 K
> jar file added to svn. It's relatively light weight and it  
> shouldn't be
> changed often (if at all).
>
> How to people feel about including the WebSphere APIs in this way?  
> On the
> one hand it make the code quite a bit easier to maintain, but on  
> the other
> hand it's a binary in SVN.
>
> -Mike