EJB SLSB + Remote client : can't propagate transaction

[smougenot]

In a remote client having his own transactionManager I can't propagate the transaction to the remote EJB SLSB running on JBoss 3.2.3.
Of course, the client's transaction manager is not the JBoss one (I'm using one from Geronimo, Atomikos or JOTM, not choosen yet).

The SLSB method I call are transaction Required (or Mandatory) and this bean is a CMT.
I already use a lot EJB Remoting for various tasks (extracting reports, handling flags on user demand, ...). But it is the first time I need to propagate a transaction to JBoss beans.

General question :
Is there some configuration needed on the client to be hable to propagate transactions?

If someone know some code sample or tutorial for remote client and transaction propagation please let me know where to find it.

Potential problem :
I do not have JNDI context on the client part (not running in an app server). So the client TransactionManager is not in a JNDI

Questions :
Could this prevent JBoss client code to detect the current transaction?
Is there a way to give JBoss Client the transactionManager?


I post this topic after http://www.jboss.com/index.html?module=bb&op=viewtopic&t=125668
I debug the execution and found strange behaviour of the JBoss client : it never transmit the transaction context.
According to me there is no valid TransactionPropagationContextFactory.


Config :
server : JBoss 3.2.3 + jvm 1.4
client : no app server, simple main class runing on jvm 1.5. Use Spring + Jencks as Transaction management configuration.


Thank you for your attention

[marklittle]

"smougenot" wrote:
In a remote client having his own transactionManager I can't propagate the transaction to the remote EJB SLSB running on JBoss 3.2.3.
Of course, the client's transaction manager is not the JBoss one (I'm using one from Geronimo, Atomikos or JOTM, not choosen yet).

Why would you use either of these? Why not use JBossTS? It supports distributed transactions and in a standard manner.

[smougenot]

I do not use JBossTS because of problems encountered to set it up in the environments.

At the moment, with the other ones I got an easy to use / portable configuration.
But maybe someone knows a good sample of code setting JBossTS with Spring. I'll be glad to try this implementation too.

The other part is that (according to me) I do not want to be required to use JBossTS because one part of my application uses an EJB running on JBoss.
(I'm pretty sure that if I used the JBossTS there will be no trouble because of the way the client look at the transaction informations bound to the thread).


For answering the previous questions:
(Looking at the code of the client)
There seams to be no way to get my TransactionManager implementation known to the JBoss client if you do not have a JNDI repository. (I'm missing a simple way to set it such as a factory call, a constructor or a setter but there is no way I could found).

So I'll try Spring SimpleNamingContext to build a JNDI repository and try to get JBoss client using it.

I'll tell the results.

[marklittle]

"smougenot" wrote:
I do not use JBossTS because of problems encountered to set it up in the environments.

What problems?

At the moment, with the other ones I got an easy to use / portable configuration.
But maybe someone knows a good sample of code setting JBossTS with Spring. I'll be glad to try this implementation too.

Checking the wiki is always a good idea.

The other part is that (according to me) I do not want to be required to use JBossTS because one part of my application uses an EJB running on JBoss.

You lost me again. What has that got to do with JBossTS? We're a stand-alone transaction engine and have been long before the ones you mentioned. It's also always a good idea to read the blog.

(I'm pretty sure that if I used the JBossTS there will be no trouble because of the way the client look at the transaction informations bound to the thread).


For answering the previous questions:
(Looking at the code of the client)
There seams to be no way to get my TransactionManager implementation known to the JBoss client if you do not have a JNDI repository.

Read the JTA documentation that comes with JBossTS. You'll see that you don't need JNDI to get access if you're running stand-alone.

[smougenot]

Great help !! I'm surprised by your posts!!
I'm glad to see how helpfull you are.

So if I understand you well
1
I have to use JbossTS in my stand-alone client if I want help.
2
If people got problem with other tools refer to 1 :
Other tools are not likely to "support distributed transactions and in a standard manner".
3
If people are in trouble with JBossTS: they are in trouble because they didn't read docs. (as a reminder : I do not use JBossTS in the stand-alone client)

[Yes I react strongly because I do not think my questions deverved that offending treament. Can't support be done gently. In my position I've to support other and I can't act that way.]

Checking the wiki is always a good idea.

We're a stand-alone transaction engine and have been long before the ones you mentioned. It's also always a good idea to read the blog.

To be clear : THIS QUESTION IS NOT ABOUT USING JBossTS STAND-ALONE!!!!!!
I'm sure this is a good tool when you use it in stand-alone but i'm not.
As I told you I can't use it in my environments.

What problems?

Because it is too diffcult to maintain (you need to install it, make sure it runs well, have people monitoring it ...) it's too much of a burden for the little application I have to build (my boss rejected that overload).

As a matter of fact I did search the documentation about the transaction service in my JBoss (3.2.3) and how to use it with remote client and distributed transactions. But I couldn't find it. Sory about that (but browsing thousands of pages and all resources I found about JBoss 3.2.3 about remoting and transaction did not gave me the solution).
That's why I use this forum!

After that I had to look into the code in order to check what is the problem. Of course I couldn't find out (there is a lot of code and I may not have enough background especialy in transaction distribution mechanism).
But I found some JNDI call so I ask for help about it.
And what did I get as an answer .... see above.

I repeat to be clear : I'm using existing stuff on a JBoss 3.2.3 and I need to access it with a stand-alone remote EJB client and having transaction propagation working.
Obviously it is the client code bundled with JBoss 3.2.3 (nothing related to JBossTS and it's installation in the stand-alone client ... I do not use it in the stand-alone client).

My need is to point out what's wrong with the stand-alone client environment NOT TO SET UP JBOSSTS in it.


What I found into the Client.
Maybe it can work without JNDI but I'm not convinced.

org.jboss.tm.usertx.client.ClientUserTransactionObjectFactory
 /**
 * Get the <code>UserTransaction</code> this factory will return.
 * This may return a cached value from a previous call.
 */
 static private UserTransaction getUserTransaction()
 {
 if (userTransaction == null) {
 // See if we have a local TM
 try {
 new InitialContext().lookup("java:/TransactionManager");

 // We execute in the server.
 userTransaction = ServerVMClientUserTransaction.getSingleton();
 } catch (NamingException ex) {
 // We execute in a stand-alone client.
 userTransaction = ClientUserTransaction.getSingleton();
 }
 }
 return userTransaction;
 }

ClientUserTransaction

 /**
 * The RMI remote interface to the real tx service
 * session at the server.
 */
 private UserTransactionSession session = null;

 /**
 * Create a new session.
 */
 private synchronized void createSession()
 {
 // Destroy any old session.
 if (session != null)
 destroySession();

 try {
 // Get a reference to the UT session factory.
 UserTransactionSessionFactory factory;
 factory = (UserTransactionSessionFactory)new InitialContext().lookup("UserTransactionSessionFactory");
 // Call factory to get a UT session.
 session = factory.newInstance();
 } catch (Exception ex) {
 throw new RuntimeException("UT factory lookup failed: " + ex);
 }
 }

In the code below getTransactionPropagationContext() is always return null.

JBoss client code that invoque the EJB SLSB

public Object invoke(Invocation invocation)
 throws Exception
 {
 // We are going to go through a Remote invocation, switch to a Marshalled Invocation
 MarshalledInvocation mi = new MarshalledInvocation(invocation);

 // Set the transaction propagation context
 // @todo: MOVE TO TRANSACTION
 mi.setTransactionPropagationContext(getTransactionPropagationContext());
...

Could someone tell me where to look in order to find what's wrong.
Please help!

[marklittle]

"smougenot" wrote:
Great help !! I'm surprised by your posts!!
I'm glad to see how helpfull you are.

You are most welcome.

Please remember: these are FREE BEST EFFORT FORUMS. If you really need more immediate help then get a support contract. Otherwise you will have to wait in line for help while we deal with those higher priority cases.

So if I understand you well
1
I have to use JbossTS in my stand-alone client if I want help.
2
If people got problem with other tools refer to 1 :
Other tools are not likely to "support distributed transactions and in a standard manner".

If you want to read that into what has transpired then that's entirely up to you.

3
If people are in trouble with JBossTS: they are in trouble because they didn't read docs. (as a reminder : I do not use JBossTS in the stand-alone client)

See above: these are FREE BEST EFFORT FORUMS. We have paying customers who get priority. If you want to join that list, then let us know. Otherwise, we do our best. If that's not good enough for you, then so be it. Believe it or not, we're trying to help you. Given that we've spent several decades working with transactions, I'd assume you would want that help. But obviously not.

So we do expect people to read the manuals. Since we've worked on them for the best part of 20 years, you would help us to help you if you check the copious documentation first. We went to the effort to make them as good as possible, so do us the respect of checking them when you can. Thanks.

[Yes I react strongly because I do not think my questions deverved that offending treament. Can't support be done gently. In my position I've to support other and I can't act that way.]

"offending treatment"? I think you're reading far too much into the previous discussion. You are making subjective statements. Please take them elsewhere.

Checking the wiki is always a good idea.

We're a stand-alone transaction engine and have been long before the ones you mentioned. It's also always a good idea to read the blog.

To be clear : THIS QUESTION IS NOT ABOUT USING JBossTS STAND-ALONE!!!!!!
I'm sure this is a good tool when you use it in stand-alone but i'm not.
As I told you I can't use it in my environments.

What problems?

Because it is too diffcult to maintain (you need to install it, make sure it runs well, have people monitoring it ...) it's too much of a burden for the little application I have to build (my boss rejected that overload).

OK. I assume you have done the necessary checks for what a good, reliable transaction system should provide and come to the right decision. Good for you. I personally see no reason to assume that it is any more of a burden than the other engines you have chosen. But then again, I have tried them all so I do have something to compare to.

As a matter of fact I did search the documentation about the transaction service in my JBoss (3.2.3) and how to use it with remote client and distributed transactions. But I couldn't find it. Sory about that (but browsing thousands of pages and all resources I found about JBoss 3.2.3 about remoting and transaction did not gave me the solution).
That's why I use this forum!

JBossTS is not in JBossAS 3.2.3. That's the old JBossTM which is no longer supported. So that's another reason we'd recommend using JBossTS. But let's not go back over that story, shall we?

After that I had to look into the code in order to check what is the problem. Of course I couldn't find out (there is a lot of code and I may not have enough background especialy in transaction distribution mechanism).
But I found some JNDI call so I ask for help about it.
And what did I get as an answer .... see above.

Look, you did get help. If you don't want it, then don't complain!

I repeat to be clear : I'm using existing stuff on a JBoss 3.2.3 and I need to access it with a stand-alone remote EJB client and having transaction propagation working.
Obviously it is the client code bundled with JBoss 3.2.3 (nothing related to JBossTS and it's installation in the stand-alone client ... I do not use it in the stand-alone client).

My need is to point out what's wrong with the stand-alone client environment NOT TO SET UP JBOSSTS in it.

Sorry, but we no longer support JBossTM, which is the one in JBossAS 3.2.3. I'll repeat what I said earlier: replace JBossTM with JBossTS and then you'll be able to get access without JNDI.

[marklittle]

BTW, I really have to ask this question: since you've obviously done your homework, you do realise the significant problems with continuing to use JBossTM (the old transaction manager in JBossAS 3.2.3)? I assume your boss knows the risks you run by combining it with other transaction managers in the way you describe?

[smougenot]

It took you 4 posts to read the first lines of my post:

In a remote client having his own transactionManager I can't propagate the transaction to the remote EJB SLSB running on JBoss 3.2.3.

and tell me

Sorry, but we no longer support JBossTM, which is the one in JBossAS 3.2.3

What a hell it was to have this simple answer!
Thank you mark (other people could stop reading here)

For your personal understanding mark : You assume I'm (or my boss) in charge of the old application on JBoss 3.2.3. But we are not. We try our best to do the job with what constraints we have.

If you really need more immediate help then get a support contract.

I never asked for that.
I just asked if there was something particular to do when I couldn't found information elsewhere. This is the supposed usage of that kind of forum. I even tried to debug the code before asking in order to save time to everyone.

BEST EFFORT FORUMS

Did you look at your first post :

Why would you use either of these? Why not use JBossTS?

You even miss the fact that I was using JBoss 3.2.3 because you focused on the fact I didn't wanted to use JBossTS (reminder: it was not qualified by my chef).

[marklittle]

"smougenot" wrote:

For your personal understanding mark : You assume I'm (or my boss) in charge of the old application on JBoss 3.2.3. But we are not. We try our best to do the job with what constraints we have.

I don't make any such assumptions. I do however, hope that you want to do the right thing as far as transactions are concerned. So far I am not sure that is the case. On the one hand you talk about ACID transactions, but on the other hand you clearly do not understand what is involved and how the transaction manager in JBossAS 3.2.3 does not fit your needs. That was what I was trying to illustrate and why I was trying to encourage you to consider JBossTS.

If you really need more immediate help then get a support contract.

I never asked for that.
I just asked if there was something particular to do when I couldn't found information elsewhere. This is the supposed usage of that kind of forum. I even tried to debug the code before asking in order to save time to everyone.

And you received appropriate responses. Don't complain on a free forum if they were not enough for you to figure out.

BEST EFFORT FORUMS

Did you look at your first post :

Now that's a silly question, isn't it ;-) What do you think?!

Why would you use either of these? Why not use JBossTS?

You even miss the fact that I was using JBoss 3.2.3 because you focused on the fact I didn't wanted to use JBossTS (reminder: it was not qualified by my chef).

Oh, no I definitely did not miss the fact that you were using JBossAS 3.2.3. I think you may have missed the fact that I've been working in the area of transactions for over two decades, and maybe, just maybe, can better direct you away from future issues before you get to them.