• Post Reply Bookmark Topic Watch Topic
  • New Topic

Entity Bean Question  RSS feed

 
Rajesh Shiggaon
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys:

While I was going through the EJB specification I found this statement, which made me some what confused
"While a crash of the Java Virtual Machine may result in a rollback of current transactions, it does not destroy previously created entity objects nor invalidate the references to the home and component interfaces held by clients"

If the client has a reference to the EJBObject, the JVM of the application server crashes and comes up after some time. Once it has come up, the client calls a business method through the EJBObject. How the container takes care of this. How is this possible?
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The client does not have a reference to the EJBObject. The client has a stub that communicates with the EJBObject. The EJBObject is a server-side artifact. Since entity changes are transactional, I think the point of the spec statement is that whatever existed and was committed before the crash will still exist after the recovery. Any remote stubs referring to those already-existing entities can still be used.

This doesn't ensure you won't get some kind of exception in your client code when the JVM crashes and recovers; after all your transaction was killed during the crash. It just means that you should be able to write recovery code the re-uses the existing entity bean home and instance client-side stubs instead of having the overhead of getting them all over again from JNDI.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the client has a reference to the EJBObject, the JVM of the application server crashes and comes up after some time. Once it has come up, the client calls a business method through the EJBObject. How the container takes care of this. How is this possible?

The client's stubs communicate with something on the EJB server. That something might be a tie (an entity accessible via IIOP that has a method that dispatches calls to the EJBObject). When the server is restarted, it recreates the tie. When the EJBObject is recreated, the server will link it to the tie. So, if all goes well, the client can simply reuse the stub it already has to invoke business methods.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roger, wondering if you might know something... I'm guessing that all of this is a Corba leftover. Something like requiring (skeleton?) activation for POA. I never kicked around the Corba tires enough to get a lot of depth, wondering if that sounded about right? If so, then the spec'd behaviour might have less to do with being nice to EJB coders, more to do with the bits of Corba compliance Sun tried to allow.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, it's certainly about CORBA compliance, but it's more than a leftover. In order to enable interoperability between EJB Container implementors, the EJB 2.0 specification mandates support for the IIOP 1.2 protocol (which is part of the CORBA 2.3.1 specification) for remote invocations on EJBObject and EJBHome references.

The EJB spec does try to make life easier for developers. This is what it has to say.


Ideally, a remote client should be able to use an object reference across
a server crash and restart. An object reference should become invalid only when the entity object has been removed, or after a reconfiguration of the server environment (for example, when the entity bean is moved to a different EJB server or container).

The motivation for this is to simplify the programming model for the entity bean client. While the client code needs to have a recovery handler for the system exceptions thrown from the individual method invocations on the home and remote interface, the client should not be forced to re-obtain the object references.
 
Rajesh Shiggaon
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ideally, a remote client should be able to use an object reference across
a server crash and restart. An object reference should become invalid only when the entity object has been removed, or after a reconfiguration of the server environment (for example, when the entity bean is moved to a different EJB server or container).

The motivation for this is to simplify the programming model for the entity bean client. While the client code needs to have a recovery handler for the system exceptions thrown from the individual method invocations on the home and remote interface, the client should not be forced to re-obtain the object references.


I was just wondering, when a server gets crashed
1) skeleton on the server gets destroyed.
2) EJBObject gets destoryed.
3) EntityContext object also gets destroyed withe JVM crash (Which contains UserTransaction, holds the information abt the user), the primary key object etc.
So when it comes up how all these objects gets constructed? how come the client still is able to communicate with the entity bean?

Thanks
Rajesh S.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!