Not sure if this is the proper forum for this question, but would seem possible.
We currently have a web application deployed to a Glassfish server. We are needing to communicate to an application deployed to a JBoss server at various points during our applications lifecycle.
In order to establish the connection to the JBoss server it is necessary to set environment naming properties in our environment while the call is made, and then swapping them back out to the original Glassfish naming properties when complete so local calls in the server can resolve.
So to make the call we save off the current set of GF of properties, and make a call to set them to the JBoss system like this:
then make the call, and then reset to GF properties after completion. The problem with this is while the call is being made (and there could be many in succession so there is no way to know how long or how often such a connection will be used) no local calls from the GF appserver is possible, for example a datasource defined in the JNDI service through GF.
It would appear that to use this system as is, it would be necessary to synchronize on all methods that may make a local call while a remote JBoss connection is in progress, and the opposite when local calls are in progress. First I'm not sure if this even possible, and 2nd this gets exponentially more complicated as multiple users hit our web application(s).
My take on this, I have a few options.
Try do do what I stated above (don't think it's possible)
Deploy my web application to the same JBoss server as the service I'm calling (don't know now whether this is possible)
Make my application a standard client application to do away with the possibility with other users stomping on my environment.
Maybe there's another solution that I'm not considering? Ideally I'd like to keep the current configuration as it is to save time reworking (it wasn't my idea to set it up this way, I inherited this when contracted out to help them out of this mess), but if my hunch is correct I don't see how it can be maintained properly and scalability would be a huge problem.
That is what I'm doing. Problem is (I believe) is this...
This context switching is performed in a library that a client will be interfacing with, this client in this context is a web application which (obviously) possibly multiple users can be using. If I go changing the initial context to one state at the same time another user of the client application is wanting (expecting) to use the "real" initial state, then it will fail.
Since the controlling of this state isn't in the client's hands directly there stands to be the real possibility that, yes, a method could be authored that mixes the two contexts up, and should be.