• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

question about the entity bean lifecycle

 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hello, anybody can help me?
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
william shen
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Kyle.
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot Chris, i really appreciate it.
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Chris Mathews
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Notice the key word: good.
 
reply
    Bookmark Topic Watch Topic
  • New Topic