• 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:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

EJB Questions on SFSB, please help!

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello guys!

I have few questions on Stateful Session Bean, I would be very thankful if somebody will help me out. Thanks!

Let's imagine that we have SFSB (Stateful Session Bean).
To access it we get his Home reference, then EJBObject reference.

Technically and practically we can then serialize it. Two ways for that.
First, we use getHandle() method of EJBObject interface to get serializable handler (because EJBObject is a stub, right) and then we serialize it. To de-serialize we do that and get Handler object, then we call getEJBObject() of Handle interface to get our actual EJBObject reference.
Second, we can just simply use HandleDelegate and it's methods which operate directly with EJBLocalObject and EJBObject.

We can then save serialized data into file or may be into field of database.
I believe I do not have mistakes till this point.
Now my questions.

#1

Once serialized and stored into file or database field client will exit. Will Application Server still keep SFSB alive? Will Application Server know that there is an active (is it considered to be an active?) reference to it? Will it maintain SFSB state? Or serialization into file/field of database is not considered to be an active reference? So is the only way out to put everything only into HttpSession?

#2

If still Application Server is going to keep SFSB and maintain it's state, so how long it will last? There could be a situation when client will never return, or will return in a week. Is there a possibility to limit SFSB and it's state maintaince for an Application Server for some period of time? Somehow? How? And what will happen if Application Server will restart? Will all SFSBs return back alive and with their old states?

#3

Let's imagine that everything works. But we have the following structure. One client (servlet it will be) will start interaction with SFSB, then will save a reference into file or field of database. Exit. And then other client (Swing application) will load reference from file or field of database and will want to work with the same SFSB with already created state (done before). Will this be possible? Or SFSB needs to same client? How SFSB understands something about it's client (same/not?)? What if it's a different servlet? Or the same servlet, but other (new) instance of it? Etc.?

Thank you very much for any help! I really need to find answers to these questions!


---
Panda Mima, [email protected]
 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are correct about the Handle and its serialization portion, but I am not sure how you are able to get a reference to HandlerDelegate which is a part of the EJB SPI, i.e. only the ejb implementor/vendor will have access to the HandlerDelegate object.

#1
So long as you maintain a reference to the SFSB and you are invoking the bean methods in the context of a transaction, it will remain alive. The container will passivate only if the bean is in between transactions.

#2
The application server maintains the state until the client explicitly calls remove() on the SFSB or if the bean timeout occurs, whichever is first.

#3
It will depend on the time interval between the swing and the servlet interaction. However SFSB passivation implementations of application servers are not robust or consistent. Instead I would recommend you go for storing state in some sort of persistence mechanism like database, file etc.
 
reply
    Bookmark Topic Watch Topic
  • New Topic