Update EJB's on a running server instance

[tom_doehler]

Hi,

is it possible to update EJB's (or even whole applications) while clients access ressources on the application server?

I saw something equal in the manuels of HP-AS. It has the facility (on paper , i didn't tried it yet) to update a running application, while clients are using the application.

I wonder if something similar is possible with jboss? I looked thru the docus but there are no hints about doing something like that.

Bye Tom

[tom_doehler]

Ok,

i did some testing by my own and found out, that jboss always undeploys any deployed jar/war/ears before it redeploys it.

Wouldnt it be better if jboss could handle different versions of deplyoed apps?

So it would be possible to deploy a newer version of an application, and all new users (respective sessions, clients or whatever) would obtain a handle on the newer deployed component, while existing users (respective sessions etc.) use their (older and already deployed) version.

Maybe something similar can be done using different versions of applications in diffenrent jndi-subcontexts.
My idea is that all components of an application register in a subcontext with a version number, lets say a simple session bean is registered under the context "myapp/v1.0/SimpleSession".

Now some webclients make connections to the appserver and get some remote handles to SimpleSession.

Now I do some improvements on my SimpleSession, and register it in jndi under "myapp/v1.1/SimpleSession".

Existing clients could continue use their handles for "myapp/v1.0/SimpleSession", while new clients should use the SimpleSession v1.1 .

To avoid touching the code of my clients to tell them to use "myapp/v1.1/SimpleSession" in jndi-lookups, i could use a service-locator pattern that is configured thru an xml-file, and every call to the service locator returns now a handle for SimpleSession v1.1 .

What do you guys think, is there a main failure in this architecture or would it possible to implement this ?

Bye Tom

[davidjencks]

We've talked about a couple of other ways of getting this kind of functionality, based more on the mbean philosophy of jboss.

1. Service lifecycle operations block invocations. If you stop an mbean, invocations are blocked and wait for it to restart. This is pretty easy and will probably be implemented soon.

2. versioning mbeans. The proxies don't need to change, just their mbean invocation target. Each package deployment gets a version id in the names of all the mbeans (such as ejb containers) that result, like

jboss.j2ee:service=ejb,url=blah,type=entity,version=10101010

When you deploy a new version of an mbean (such as an updated ejb container), you get essentially new copies of all the mbeans, but with incremented version id. When a proxy looks for its mbean target, it does an mbean query for all versions of the mbean, and invokes the one with the highest version id. I think for consistency you need to make it so that once a version id is associated with a thread, you have to stay at the same version id for all subsequent calls.

We've talked about (2) but no one has said "Lets do this NOW" yet. What do you think?

[tom_doehler]

Hi,

I actually don't know mutch about the JBossMX but your idea sounds good ;-).

We are going to do some tests with the implementation based on different jndi contexts and the service locator.

If you are interested in what we found out, let me know.

Bye Tom