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 <[EMAIL PROTECTED]> 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 > > > >
