JBossTM standalone with transaction propagation over RMI IIOP

[sujes]

Hey,

I'm currently developing a prototype app using JBossTM along with hibernate/JTA and spring. It runs inside of JBoss 6 and I'm using JRMP to implicitly propagate transactions accross two instances of my app server by calling a remote EJB. I would like to move my app outside of jboss and use the transactions/jts as a standalone library. I intend to use RMI IIOP to propagate transactions between my app servers but reading the documentation I'm getting a bit confused.

In the documentation for 4.16.4 final (and any other version I've looked at) it says that I need to generate my RMI stubs using a special JBossTM compiler. This stub compilation is necessary to add support for the implicit propagation of the current transaction over remote calls. This makes perfect sense to me and it gives the example:

java com.arjuna.common.tools.rmictool.RMICTool <parameters>

The problem I have with this is that I can't for the life of me find this RMICTool class anywhere. I don't see it in the distribution or in any of the jars in the distribution or in any of the jars of my jboss distribution. I can't find any info on the net other than various versions of the docs which have this section.

My question is, how do I get my hands on this class? Or is this class even necessary? If I initialise all of the ORB black magic will it automatically pass any transactional context? I tried reading the docs but I'm afraid I'm not very clear.

Any information is much appreciated,

Simon

[jhalliday]

> I would like to move my app outside of jboss and use the transactions/jts as a standalone library. I intend to use RMI IIOP to propagate transactions between my app servers

Umm, if you move it outside of JBoss then you have no app servers to propagate between. Could you clarify your architecture please? The way that you run a pure CORBA client/server pair is different to the way you use a standalone client to talk to an app server and different again to the way you use an app server to call an standalone server. Not to mention the thorny question of which processes host the transaction manager and recovery manager.

[sujes]

When I talk about my app server, I don't necessarily mean a j2ee app server. I would like it to run as a webapp in a really lightweight webapp container such as tomcat although even an entirely standalone java app would do. At the back end there's a single database handling persistency. It receives REST HTTP post requests which invoke an atomic action and return success or failure. That atomic task is basically to update the balance of several CustomerAccounts.

There'll be a fixed number of instances of this server each with a seperate database backend. Each instance controls a subset of these CustomerAccounts. It's partitioned in a predetermined way. A request will potentially update accounts in more than one instance.

I would like each instance to be able to function in an entirely standalone way. If the request affects only customer accounts that instance, it should begin and commit the transaction itself. For this reason I imagine that there will be a corresponding transaction manager for each instance.

However if customer accounts from more than one instance are affected, I want to distribute a transaction accross the instances. I picture that one instance (the one that receives a request) will act as a kind of driver for the process; it will begin the transaction and invoke the other instances which will take part in the same transaction. So my app controls a UserTransaction from JbossTM and my expected benefits from using JbossTM is that it'll correctly manage the XA resources that are the databases and it can propagate a single transaction accross my several instances.

So I'll have a fixed number of servers and I want each to have a transaction manager. I don't really have a concept of a client which will take part in a transaction. I have built the above architecture using JBoss as an app server but if I can run the transaction manager solo then the only thing I'm using the app server for is for an EJB remote call from one instance to another. If that was an RMI IIOP call then I could run outside of JBoss.

I admit that I haven't thought about the recovery manager but can I somehow embed the transaction and recovery managers in my application?

[tomjenkinson]

AS7 is actually very lightweight I would encourage you to upgrade to AS7 and see if you still want to break your application out of the AS. Note also we have a REST-AT implementation (https://groups.google.com/forum/?fromgroups#!forum/reststar-tx) which deploys  into AS7.

[sujes]

Ha ha. Thanks. You're probably right. I've actually already recommended that we run inside an AS because I think there's lots of man hours involved in pulling it out. I'm waiting for feedback from high up.

But still though, I would like to know about the mysterious line in the documentation:

java com.arjuna.common.tools.rmictool.RMICTool <parameters>

Does this class exist? Or is it an old functionatlity that was removed but still hangs around the doc? My impression is that it should be possible to pull out but there's a few gaps that make it unclear how I can do it. I would still like to be able to estimate how long it would take to do.

[tomjenkinson]

Hi Simon,

RMICTool is part of the legacy toolchain and is no longer required. I have removed references to it from the latest version of the docs (subsequent to this conversation). With later version of TS it should just be a case of registering the correct interceptors: http://docs.jboss.org/jbosstm/5.0.0.M1/guides/narayana-jts-quick_start_guide/ch02.html

I would definitely suggest you go down the AS7 route as the AS adds very little overhead.

Tom

[sujes]

Hi Tom,

Thanks a lot. That definitely explains the stub compiler. I'm pushing hard to deploy inside the AS. The memory/performance overhead seems to be less of an issue than being bound to JBoss. Moving to another app container would not work in my opinion. I've tried setting this up in glassfish and it's even unclear whether it actually supports propagation of the transaction over iiop is supported. If it is I couldn't set it up.

I'm still quite intrigued about the interceptors. From what I understand from the link then I need to set the propagation mode first e.g.:

JTSEnvironmentBean.setContextPropMode("CONTEXT");

Then later on I must initialise the interceptors. Here's how I understand it:

Orb orb = com.arjuna.orbportability.ORB.getInstance("MyServersUniqueId");//this figures out which ORB I'm using

RootOA oa = OA.getRootOA(orb);

orb.initORB(new String[] {}, null);//this will load the jbossts-properties.xml which have the interceptors configured

oa.initOA();//does this mean that from now IIOP calls are intercepted and propagate transactions?

...//then some time later... at shutdown?

orb.destroy()

oa.destroy()

Thanks again,

Simon

[tomjenkinson]

Hi Simon,

In theory you shouldn't be bound to a specific app server for this as it should all be possible with standard JEE6, however once you try AS7 you won't want to go back

Your code looks good, the one thing I would say is that you only need:

JTSEnvironmentBean.setContextPropMode("CONTEXT");

If you are wanting to use Context based propagation. You can leave this call out if you want to use Interposition. Obtaining the ORB via orbportability does enough initialization for that - assuming you have the properly configured jbossts-properties.xml available (it shouldbe, its in the jbossjts.jar).

Note your code is going to need to implement the CORBA requirements around org.omg.TransactionalObject, personally I really do think you will be creating an awful lot of work for yourself cracking this out of EJB, e.g. resource enlistment (org.omg.Resource).

Tom

EDIT: TransactionalObject is actually deprecated sorry, transactional nature should be set by a POA attribute now

[sujes]

Hey Tom,

Thanks again! You're a legend!

I've done some research on a few JEE6 app servers and really only JBoss has clear documentation on this feature.

At this stage, my standalone implementation is probably theoretical. But with regard to the other work around implementing this, roughly what do you expect? For resource enlistment, I've experimented with using the TransactionalDriver with hibernate (rather than a datasource managed by Jboss/JCA). It seems to enlist the resource itself which is quite nice. Looking at some other docs and articles, the TransactionalDriver works well outside of the AS. Here's what I had imagined:

-So if I have serverA and serverB

-Both have initialised the ORB's as in above post

-serverA begins a jbossts transaction "tx"

-serverA enlists resourceA to tx (in my app this would involve executing db statements through the TransactionalDriver)

-serverA remotely calls serverB over iiop expecting tx to be implicitly propagated accross to serverB

-serverB enlists resourceB to tx and returns to serverA

-serverA commits tx and jbossts does it's magic and takes care resourceA and resourceB

The part which where I think I'm missing machinery is when resourceB is enlisted. I'm sure there's lots of logic to make this resource be committed from serverA. Would serverB have to be some enlisted as a resource or some other type of actor in the transaction? Or perhaps the jbossts transaction manager at serverB will do something to enlist/register itself with the one on serverA.

Sorry to keep the topic alive but I've done a fair bit of reading and I've just got to know haha.

Thanks for your time and patience,

Simon

Message was edited by: Simon Mc Glynn Perhaps the term I'm looking for when I say that transaction manager must enlist is "interpose". My question then boils down to, if I have set-up the interposition interceptor along with the ORB, is that enough to get resourceB committed? The transaction manager on server B would be coordinated by the transaction manager on server A.

[tomjenkinson]

Hi Simon,

Assuming you werent using something like JCA/TransactionalDriver on server b, your app would need to get a handle on the transaction and enlist the resource directly. You would also need to configure a recovery manager with a plugin (you would provide, fairly simple) to get a list of indoubt transactions from the resource manager (the resource manager would provide that bit). And also, you would need to provide that on server A too anyway, TransactionalDriver doesn't get the list of indoubt transactions into the recovery manager.

As you can see, the AS takes care of a lot of that for you

Also, its not particularly significant as you haven't done the work yet but the TransactionalDriver is (currently) deprecated moving forward (5.x), we are going to be recommending folks download the (lightweight) IronJacamar (JCA) container for enlistment. It should only be an extra Jar dependency and a bit of code/config. If you are interested, we could work together on that part: https://issues.jboss.org/browse/JBTM-809

Tom

[sujes]

Hi Tom,

Yes, I would be very interested in working on that together, thank you very much. The perfect world would be able to configure an XA datasource in ironjacamar and then be able to run inside of the AS or in some other simpler container depending on other requirements.

IronJacamar seems very tailored to working in an app server. From the doc I'm not really clear how I could integrate it into some kind of standalone environment. Is there any particular documentation that you can recommend to me? I was looking at http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html_single/

Is there a starting point?

Thanks,

Simon

[tomjenkinson]

Hi Simon,

Your scenario is the same that we would be heading for so that is good

You might find this information useful: http://docs.jboss.org/ironjacamar/developerguide/1.1/en-US/html/standalone.html

That said, the issue that we have is that ironjacamar can currently only embed the JTA transaction service. It shouldn't be a big deal to get it to embed JTS (perhaps via config) but that work hasn't been done in the standalone case (to the best of my knowledge).

By the way, if you are interested in working on this, can I suggest that you download the Narayana (5.0 version) of transactions: https://github.com/jbosstm/narayana but we should move conversations about that to a different thread to make it easier to search the forum?

Tom