Coffee Cream question

[alzamabar]

What's true about the client's view of an entity bean's remote component interface? (Choose all that apply)

A. Multiple clients can access the same entity object concurrently
B. New entity beans can be created using a method in this interface
C. Entity beans may not survive a crash of the container
D. Business methods cannot return a reference to the entity object

I answered A,C but the correct one was only A.

I answered C, because if the EJB container crashes, the entity beans (not the entities) cannot survive. What's wrong with it? When Jboss runs out of memory (and it crashes), if I try to re-use the entity object, I get exceptions.

[Dan T]

Well, I dont know how, but according to spec 9.1, it can survive a crash

[Severin Stoeckli]

I agree with you, Marco. The physically Entity Bean will for sure crash too. As Ryan Mentioned, the spec 9.1 says the following:


Each entity object has an identity which, in general, survives a crash and restart of the container in

Means, if I interpret that right, that "in general" the client doesn't notice a crash and restart of the container.

Severin

[Valentin Crettaz]

When Jboss runs out of memory (and it crashes), if I try to re-use the entity object, I get exceptions.
Use another application server On Weblogic, I've never had any similar problems...

[Me]

Originally posted by Marco Tedone:
What's true about the client's view of an entity bean's remote component interface? (Choose all that apply)

C. Entity beans may not survive a crash of the container

I answered A,C but the correct one was only A.

I believe this question is kind a tricky and confusing.
If we think about a particular instance that was playing as entity bean at the time of crash then that instance would definitely not survive (no matter what kind of bean it is EB, SB, or MDB it is a history)

BUT what a minute...

Entity Bean is a realization of something that exists in a persistance store (database) and as long as data is in the database it can keep come back in the form of an entity bean. Given that a container crash would not affect database (because it is persistence store) Entity beans may survive a container crash. And IMHO, this is what the survival is meant by specs.

[Eusebio Floriano]

I understood this question as the same thing that happens if a Entity Bean throws an system exception.

The client�s view is that the entity is right there. If he calls a method on component�s interface, the container must alocate another bean represeting this entity.
The same thing if the server craches. If the server didn�t startup again, ok, the client will receve an exception but if it startups it�s transparent to the client.

Here my two cents.

[alzamabar]

Sorry guys, but one thing is: the entity as something that represents an underlying entity in the persistent storage. Another is an entity bean, i.e. a way of viewing the underlying data in an object oriented way.

An entity bean is created only to map an underlying entity in the persistent storage. It the server crashes (this is how I read the question) dies, as it's true that the underlying data will survive, the entity bean instance will die, no matter of which application server you're using. That's why I answered A and C.

[Paulo Asterio Nunes]

Hi guys,

In fact ,
When Jboss runs out of memory (and it crashes), if I try to re-use the entity object, I get exceptions.

Is that because are diferences between Weblogic and Jboss commit implementations or not ???

That�s my question....

Thanks all.,


Paulo Asterio Nunes

CNA,MCP,OCP,IBMWSADCD,SCJP,SCWCD

[Dan T]

spec 4.3.2

The entity, its primary key and its remote interface survive the crash of a EJB container.

[alzamabar]

Originally posted by Ryan Wong:
spec 4.3.2

The entity, its primary key and its remote interface survive the crash of a EJB container.

From spec 4.3.2.

The entity, its primary key, and its remote reference

An entity *is* the underlying data (read: the row in the database), as its primary key is the primary key defined in the database (note: no primary key class, primary key);
The entity remote *reference* is the stub that the client has got, and not the component interface reference on the server's heap.

It's true that the entity and its primary key survive (I would be surprised of the opposite); but the physical entity (bean instance), with all related classes don't.

[Joe Nguyen]

The client�s view is that the entity is right there

Suppose an entity bean was in the middle of the transaction while the container crashed. Unless the container had saved the entity state somewhere just before it died, the client would notice the differences when interacting with the bean after the container have been restored.

[Eusebio Floriano]

Originally posted by Joe Nguyen:
The client�s view is that the entity is right there

Suppose an entity bean was in the middle of the transaction while the container crashed. Unless the container had saved the entity state somewhere just before it died, the client would notice the differences when interacting with the bean after the container have been restored.

When the stub couldn�t get an return from the container, it would rise an RemoteException. The client will be notified that something happened. I�ve never tried but i **think** that it�s possible (and the specs guarantees) that if the container rises again, the client would call methods on the component interface normally. Am i right ?

[alzamabar]

Originally posted by Vinicius Boson:


I�ve never tried but i **think** that it�s possible (and the specs guarantees) that if the container rises again, the client would call methods on the component interface normally. Am i right ?

I guess so.