JBOSS hot-deployment limitation problem


EJB programming & troubleshooting: JBOSS hot-deployment limitation problem

  1. JBOSS hot-deployment limitation problem (4 messages)

    I'm able to deply (hot-deploy) my (BMP) entity bean and access it (via a servlet) just fine with no problems. However, when I attempt to perform hot-deployment (for my entity bean)at the same time there are active bean instances (of the same entity bean being hot-deployed), belonging to to multi-threaded client http-servlet based requests, that are accessing (i.e. performing SQL updates), or trying to access the database; all those beans active instances through expections.

    Every time I re-attempt the test, I get a different exception raised from the bean. The exception I've seen so far are:
    - EJBException
    - IllegalStateException
    - RemoteException
    - TransactionRolledBackException
    - MarshalException: invalid remote object
    - UndeclaredThrowableException

    Initially I thuoght that it was a MySql, or an mm jdbc driver problem. However, MySql (or even the mm jdbc driver)has no problems handling parallel db transactions in any shape. Only when HotDeploy is done for the same (BMP) entity bean type that at the same time is beeing used by clients, creates/raises exceptions and causes all db transactions that are taking place at that same hot-deployment time to fail.

    When asking the JBOSS's news group, I believe that one of JBOSS's developer, replied with the following:
    Davidjencks said in the Database Forum of JBOSS.org:
    "You may be expecting too much from hot-deploy. You can deploy jars, ears, etc while the server is running, and redeploy them while the server is running, but expecting in-process requests to complete while new ones go to the new version is quite a bit harder.
    However, we have some ideas about how to make this possible in 3.0 "

    Strang; when I tried the exact same (hot-deployment) test scenario with stateless, and even stateful session bean(s) types it was doing the Hotdeployment operation succesfully with no problems, even while in-process requests were taking place, where all of these requests completed thier job just fine with no interruptions to them.

    Davidjencks may be right that I'm expecting too much. But that's what was understood unless told otherwise (e.g. feature limitations).

    It's my experience that this problem seem to only exist in the case of entity beans (BMP). While just fine in the case of session beans (stateful/stateless).
    I haven't tried MDBs, however, JBOSS implementation for entity bean container (database transaction (session) management) seem to be the only one, so far, having a problem in such scenario .....

    Given what Davidjencks said, I really look forward for JBOSS 3.0

  2. JBOSS hot-deployment limitation problem[ Go to top ]

    Does anyone know of an App Server that will let you deploy will your application is actually executing?
  3. I think Zope does. You can re-load products dynamically from the control panel, and of course all the templates can be updated dynamically. Of course there are other fun things to deal with... beside hot-deployment... :)

  4. >> Does anyone know of an App Server that will let you
    >> deploy will your application is actually executing?

    To my knowledge, the Borland Appserver does. I havent proved this 1st-hand, however their POA-based architecture is meant to allow them to hot-redeploy with running transactions.

    While I havent tried hot re-deploying on an actively loaded Weblogic server, I think that even though it supports hot deployment, it wont support a hot-redeploy without throwing errors. My observations have been that it undeploys before re-deploying - therefore at some point, there would be no deployed EJB instance to serve requests. I could easily be proved wrong here.


  5. JBOSS hot-deployment limitation problem[ Go to top ]

    I've worked with Websphere 3.5 a while ago, and I noticed similar limitations. The Websphere console allows you to deploy a new bean without restarting the application server, but this can cause problems. (Usually in the form of unexpected exceptions.)

    Because of this, we took the safest approach: each time a bean was updated, we would restart the application server (= the java process running the bean).

    ISTM that the problems are related to caching of the JAR file inside the JVM or the OS. When the file is overwritten, this causes conflicts between the old and new versions.