• 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

EJBObject Handle Caching

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,

Is it advisable to cache (persistant) the EJBObject Handle? (ie. store the Handles in a HashMap and then the HashMap to a file). When I googled this , i found some material which suggested against caching the handles.

What happens if I use the same Handle after a restart of the server?

Is it that the handle.getEJBObject() method calls the Home Object of the corresponding bean to create a new EJBObject instance/use an existing EJBObject instance?

I tried this with JBoss 3.2 (and even used the same handle when I upgraded to JBoss 4.0) and it worked without flaw even after a restart.

thanx
Aravind
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
EJBSpec states that the Handle should be valid for atleast one server restart. Please read the spec for more info.
 
Aravind Kumar
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanx for the reply..the same spec states this

"A session object handle can be held beyond the life of a client process by serializing the handle to persistent
storage. When the handle is later deserialized, the session object it returns will work as long as
the session object still exists on the server. (An earlier timeout or server crash may have destroyed the
session object.)"

This contradicts ur statement..In my case as mentioned in my post, the returned object works even after a restart..
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Aravind Nambi:
Thanx for the reply..the same spec states this

"A session object handle can be held beyond the life of a client process by serializing the handle to persistent
storage. When the handle is later deserialized, the session object it returns will work as long as
the session object still exists on the server. (An earlier timeout or server crash may have destroyed the
session object.)"

This contradicts ur statement..In my case as mentioned in my post, the returned object works even after a restart..




Dude, you never mentioned what type of bean you are using? Session or Entity?


My statement is true for entity beans ( )

entity handle is typically implemented to be usable over a long period of time�it must be usable at least across a server restart.




Are you using stateless session bean?
 
Aravind Kumar
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes,its Stateless session bean.

Why is it that the spec states different strategies for Stateless and Entity beans, takin into consideration that the handle's main purpose is to improve performance?

The JBoss's implementation of Handle of Session bean seems to adhere to that of Entity bean's, I guess.
 
Ranch Hand
Posts: 128
Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi,

I think, irrespective of the type of bean (Session or an entity), a handle, is like a cookie that you create for yourself which points to a Bean on a particular App Server, so that you dont have to always have to go through the look up process.

so as long as the Application server exists and hosts a bean with a particular JNDI name then your handle will work and returns a new instance that is currently available in the bean pool.

Correct me if my understanding is wrong
 
Aravind Kumar
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
u r rite..except for

"returns a new instance that is currently available in the bean pool"

Even if a bean instance is not in the pool(which implicity means a corresponding EJBObject instance does not exist), the handle returns an EjbObject.

I think this is where the difference in the bean (entiy/session) comes.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since the stateless session bean is pooled and does not contain state getEJBObject should always work is my strong feeling.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic