• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Sharing Objects Between Stateful Session Beans

 
Mark Garland
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

Long time since I've been around here (nearly 18mths ago when I studied for SCWCD), and I see that Christophe Verré is still at the helm! Good on you.

After a year or so becoming a DB2 DBA, I'm back to studying Java and SCBCD in particular.
I'm new to EJB so bear with me. I'm currently reading MasteringEJB4. Upto Chapter 4 - seems a good book.

My understanding:-
You have Stateful Session Beans, and the container can activate/passivate them should it be low on resources compared to the number of clients trying to access it.
The same *instance* of the bean may be reused for a different client after it's state is passivated.
As I understand it, any member variable of the bean (that's not transient) is serialized during passivation. So, for when a member variable isn't to be passivated (let's say a db connection), I should use @PrePassivate to destroy the connection, then @PostActivate to reestablish it after.

My question:-
If the above is true, it all just sounds a bit expensive. What if I want every bean to always talk to the same db, is there some way that I can designate the db connection to be shared across passivations/activations?
e.g.
1) bean being used by client. db connection present as member variable.
2) bean's state swapped out / passivated? db connection *still present*.
3) bean begins new conversation. db connection reused.

Perhaps I have to resort to some awkard JNDI lookup?
Perhaps I could put it in some helper class?
Perhaps I could store it statically on the class, but then every instance would access the same connection...

Hm... Just imagine if the bean had a million different connections to establish before it could work. There must be a neater way.


Thanks in advance,

MG
 
Dinuka Arsakularatne
Ranch Hand
Posts: 198
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
actually the same instance may not be used to serve a different client, it is only associated with one client. when a request comes back to that object, the session bean is activated with respect to the relevant EJB object associated with that request. In an application server, connection pooling is always used. So connections are usually established by the use of Datasources. Hence you would not want to create database connections by your self. If your DB connection is made through injecting to an instance of EntityManger then you do not need to handle this through @PrePassivate and @PostActivate as these are automatically passivated and restored by the container.
 
Mark Garland
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Dinuka for you reply.

It sounds to me that when I am writing my stateful beans that I should ignore the fact that the Container *may* do pooling and should write all beans as if pooling is never used. If the Container decides to use it, that's great for performance.

Beyond that, if I have large resources that take a long time to establish, I can use dependency injection to save the expense of creating them in my bean each time.

All correct?

Thanks once again,

MG
 
Dinuka Arsakularatne
Ranch Hand
Posts: 198
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"should write all beans as if pooling is never used" - This is correct

And if you have a large resource to access i suggest you use DI and if this is a DB connection,user transaction or bean lookup, then these will be correctly saved to secondary storage during passivation and restored correctly during activation. If it is any other resource then you should explicitly free it in the method annotated with @PrePassivate and then inject it back again inside the method annotated with @PostActivate...

Hope this helps

Dinuka
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic