Skip to main content

XA transaction involving resources from different networks

2 replies [Last post]
bentsou
Offline
Joined: 2008-05-20

I have a stand-alone application that talks to several EJBs on a Glassfish v2ur2 server. The stand-alone application obtains a UserTransaction to group several EJB method calls together.

Everything works fine when I run my application in the development environment where everything is on the same network. However, when the project is deployed to the production environment where the Glassfish sever and the client are now on different networks I got a connection time-out exception when the client tries to call the commit() method of the UserTransaction object.

From what I can tell, the commit request was received by the Glassfish server. But when the server tries to send out a commit acknowledgment (I think that's what the server is trying to send), it sends it to a private IP (192.168.0.x). That explains why the client can never receive the acknowledgment in the production environment.

My question is, why is the server sending information to a private IP? Is there a way that I can correct this?

My current work-around is to use container-managed transaction. However I really want to have my client application control the transaction boundary for flexibility. Or is it a bad practice that should not be used at all?

Any comment is appropriated.

Ben

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ewernli
Offline
Joined: 2007-10-21

I know there was a bug in Toplink with similiar symptoms, but it is apparently not the same problem as it works fine in dev. environment for you.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3867

Generally speaking, it is not a recommanded practice to start a transaction from the client-side. So far I know, this is an optional feature of the specifications, and not all containers will support it (especially OC4J, which would explain the issue with toplink).

Whenever possible, you should expose a facade to your client that hide the internal complexity. The methods exposed in the facade should map to your business use cases.

Concerning the IP problem, you can try to change the IP address of the IIOP listener. Instead of 0.0.0.0, try with either the hostname or the IP address. I remember we also had some issues with client installed in different subnets trying to connect to the same Glassfish instance.

bentsou
Offline
Joined: 2008-05-20

Thanks ewernli for your reply.

I think for now I will go with suggestion and start the transactions on the server-side. I will probably need to dig deeper into how the transaction manager communicates with the different resources. I suspect that's where the problem is.

Ben