File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Coffee Cream question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Coffee Cream question" Watch "Coffee Cream question" New topic
Author

Coffee Cream question

alzamabar
Ranch Hand

Joined: Jul 24, 2002
Posts: 379
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.


Marco Tedone<br />SCJP1.4,SCJP5,SCBCD,SCWCD
Dan T
Ranch Hand

Joined: Jun 15, 2004
Posts: 66
Well, I dont know how, but according to spec 9.1, it can survive a crash
Severin Stoeckli
Ranch Hand

Joined: Jul 21, 2004
Posts: 62
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
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
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...


SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
Me
Ranch Hand

Joined: Dec 01, 2003
Posts: 51
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
Ranch Hand

Joined: Mar 07, 2004
Posts: 235
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.


SCJP 1.4 / 5.0 - SCBCD 1.3 - SCWCD 1.4 - IBM 484
alzamabar
Ranch Hand

Joined: Jul 24, 2002
Posts: 379
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
Ranch Hand

Joined: Jul 06, 2004
Posts: 63
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


Regards,<br /> <br />Paulo Nunes (Brazil)<br />MCP OCP IBM285 SCJP 1.4 SCWCD 1.4 SCBCD 1.3 SCEA (I)
Dan T
Ranch Hand

Joined: Jun 15, 2004
Posts: 66
spec 4.3.2

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

Joined: Jul 24, 2002
Posts: 379
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
Ranch Hand

Joined: Apr 20, 2001
Posts: 161
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
Ranch Hand

Joined: Mar 07, 2004
Posts: 235
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
Ranch Hand

Joined: Jul 24, 2002
Posts: 379
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Coffee Cream question
 
Similar Threads
Timers and their activation/passivation
Confirmation Required
Doubts in HFEJB
Need clarification in TimerService
New Mock Exam questions...