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 and other Java EE Technologies and the fly likes question about the entity bean lifecycle Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "question about the entity bean lifecycle" Watch "question about the entity bean lifecycle" New topic
Author

question about the entity bean lifecycle

william shen
Ranch Hand

Joined: Jun 07, 2001
Posts: 60
hello,

i am new to the EJB world, i created a sample entity bean which is accessed through a stateless session bean. it seems like everytime i called the findByPrimaryKey method on the entity bean, it created a new instance of the bean even i called findByPrimaryKey with exactly the same key. is it normal, or i did something wrong. coz, why does the container create new instance of the bean everytime instead of reusing the same instance to save memory? can somebody clear this out for me? thanks in advance.
william shen
Ranch Hand

Joined: Jun 07, 2001
Posts: 60
hello, anybody can help me?
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
You need to read in the EJB spec about Option A, B and C caching. The behavior you are seeing is what is expected for Option C, where you get a new instance for every transaction. Each vendor's product vary on how you set up the caching policy in use.

Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
william shen
Ranch Hand

Joined: Jun 07, 2001
Posts: 60
Thank you Kyle.
Srinivas Kadiyala
Greenhorn

Joined: Jun 07, 2004
Posts: 13
Entity beans stay until they are deleted.Check ur program whether u hv written any where to delete the bean.

Generally when the program terminates,object is lost but entity bean stays until it is deleted.
william shen
Ranch Hand

Joined: Jun 07, 2001
Posts: 60
Originally posted by Srinivas:
Entity beans stay until they are deleted.Check ur program whether u hv written any where to delete the bean.

Generally when the program terminates,object is lost but entity bean stays until it is deleted.


Srinivas,

Thanks for your reply. i think that is not my question. my question is why the container generates new instance everytime i call the findByPrimekey method even i call it with exactly the same key. according to you reuse the existing instance(since it is not gone yet) for the same primekey would make more sense than create a new one. i think Kyle answer it. but i am still confused what is the benefit of doing this, what is the context that will fit into this policy. Since RJB spec put this as an option, it should have its use. Kyle can you explain it?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Have you read the spec like Kyle suggested? Because if you haven't then it is quite silly for us to be discussing this. Many of your questions will be answered by simply investing the time in reviewing what the EJB Specification has to say.

Having said that, I will still elaborate on the issue since I am a sucker for punishment.

The EJB Specification defines three commit options. They are named (rather stupidly) A, B, and C.

Commit Option A - This option essentially tells the EJB Container that it OwNz the database. Therefore, the EJB Container can cache bean instances between transaction and not be forced to reload database state on each access. When people talk about the advantages of Entity Bean caching in an Application Server they are usually referring to Commit Option A (though rarely do they realize that). Unfortunately, most enterprise applications (at least the ones I have worked on) must share their database with other applications and cannot use this caching option.

Commit Option B - This option tells the EJB Container that it is using a shared database. It is okay to keep the bean instance around after the client is done with it... but before it is handed out again the state must be synchronized with the database. When using this option you will *always* see ejbLoad() called when you look up an EJB, even if it hasn't changed since the last use. In general, Commit Option B is what most J2EE applications use and is the default level for many Application Servers.

Commit Option C - This option is very similar to B except that nothing is cached, not even bean instances. Therfore, for each request a new bean instance is created and ejbLoad() is called.

It is important to understand that an EJB Container is not required to support all of these Commit Options. They are just required to support at least one. The various levels are specified to give the Container freedom in decided how manage bean instances. If I had to venture a guess as to why Commit Option C is in the specification then I would probably say because it is the easiest possible option to implement. However, all good Application Servers will support both A and B. To be honest I am not sure you would see much of a performance difference between B and C, today's JVMs are very good at creating objects and the biggest hit is going to be the call to ejbLoad() anyways.
[ June 10, 2004: Message edited by: Chris Mathews ]
william shen
Ranch Hand

Joined: Jun 07, 2001
Posts: 60
Thanks Chris for your explanation.
i did not read the spec yet.

i run the example again, it seems fell into non of the options.
1. the ejbload is called only for findbyprimekey with different keys.

for example:
when i call findbyprimekey(1)the first time, it will call ejbload
if i run it for a second time, ejbload was not called, while at the same time a new instance was created.

if i call findbyprimekey with a different key findbyprimekey(2), ejbload was called and a new instance was created.

so it seems everytime it created new instance but ejbload was not always called. how to explain it
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Couple of silly questions...

1) What Application Server are you using?

2) By what criteria are you determining if a new instance is created?

3) Are you aware of the difference between a bean instance and an EJBObject instance and how they are associated? (My above post refers to bean instances only... the EJB Container can do whatever it likes with EJBObject instances.)
william shen
Ranch Hand

Joined: Jun 07, 2001
Posts: 60
1) i am using Jboss

2)i put an instance variable i to the bean class,and put a counter in the findbyprimekey method.

class samplebean implements entitybean{
private int i;

... ejbfindbyprimekey(){
i++;
System.out.println("i");

}
}
i call the findbyprimekey from client, and everytime the console output i as 1. so i guess everytime a new bean instance was created. am i right?

"3) Are you aware of the difference between a bean instance and an EJBObject instance and how they are associated? "

i do not know the answer for this question. maybe this is the problem?
william shen
Ranch Hand

Joined: Jun 07, 2001
Posts: 60
Hello, Chris are you there?

is my question too stupid? is the way i test the program wrong?
somebody please help.
william shen
Ranch Hand

Joined: Jun 07, 2001
Posts: 60
i think the ejbobject is the new name for the stub and skeleton object. IMHO from what i have done it should be the bean instance. correct me if i am wrong.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
This conversation is definitely leading into the the very detailed area of EJB Container implementations and I noticed a couple things.

1) You haven't read the EJB Specification or other supporting material so we aren't really on the same page terminology-wise. This complicates matters a lot when talking about very technical subjects. My suggestion is to read the EJB Spec and/or read Mastering EJB (in particular Chapter 5 on Entity Beans). I believe this will quickly answer most of your questions a lot faster and more effectively than we could here.

2) You are using a non-certified EJB Container that has been known to have strange behavior when it comes to the actual EJB Specification. So we can sit up here all day and tell you what the spec says but if JBoss does not fully comply with it then you are going to see different results. This is what seems to be the case with JBoss and Bean Instances here. See this report for more detailed information on the internal behavior of JBoss.
william shen
Ranch Hand

Joined: Jun 07, 2001
Posts: 60
Thanks a lot Chris, i really appreciate it.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
However, all good Application Servers will support both A and B

Don't say that, I use Sun Java� System Application Server Platform Edition 8 at home, and it only supports Commit Option B and C.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Notice the key word: good.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: question about the entity bean lifecycle