aspose file tools*
The moose likes JSF and the fly likes What is the way to acess same object from different Managed Beans? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "What is the way to acess same object from different Managed Beans?" Watch "What is the way to acess same object from different Managed Beans?" New topic
Author

What is the way to acess same object from different Managed Beans?

Daniel Reznick
Ranch Hand

Joined: Oct 23, 2008
Posts: 50

Hi, the scenario is as following :

I have a JSF app in which when the user is logged in an object it queried from the db, this object will be access from many others Managed beans during the user presence in the web app, right now im sharing this object among the managed beans in the following way:

Right after im queering the object from the db , im storing it into the session , and whenever i need the object i grab it from the session , manipulating it and putting back to session

This way seems to me a bit wrong... "grab from session put it back into the session..."

Isnt it better to create a handler class that will be singleton and put the object into this class, and from each managed bean get the class instance and from that instance get the object

The questions are:
1) This handler class, in what scope will it be placed? cause its a simple POJO
2) Which way is better
3) Are there any other ways to achieve this object access from different managed beans in the web app?

Thanks ahead!

Daniel
Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
Hi Daniel,

1)
You say you are dealing with information that must be there as long as the user is logged in. In that case, the session scope is the right scope for you. Also for the POJO.

2)
I don't like the "grab from session, manipulate, and put back on session" approach either. I think the idea to have a POJO that manipulates the db object isn't a bad idea. However, this cannot be a singleton, as you need one for each user. If you create it as singleton, you should implement a mechanism to bind a specific db object to a specific user. If you do so, you are basically re-implementing your own session scope. I think I'd put a POJO on the session and have the POJO manipulate the db object. So you grab the POJO from the session, call a method on it that manipulates the db object and then you're done.

3)
It depends on your exact requirements. Perhaps you should have a look at MyFaces Orchestra, that offers rather elegant ways to manage database transaction and keep those transactions open during what they call "conversations". I don't know your exact requirements, but this might be what you're looking for... (Note that Orchestra is covered in Chapter 9 of the Apache MyFaces 1.2 Web Application Development book.)

Best regards,
Bart


SCJP 1.4 | SCJD 1.6 | Visit my website | Author of the book Apache MyFaces 1.2 Web Application Development
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16145
    
  21

If you're using an ORM for your persistent data storage, you'll generally have the advantage of transparent caching, so you don't actually need to hold the object itself, just enough information to obtain the object. In the case of a user account record, in fact, I've done exactly that, using the user's login ID to retrieve the record as needed. A variation on that theme that works better for some systems is to obtain the object's "handle" and resolve that instead of doing an actual find operation. The handle requires minimal storage and is serializable if stored in your session.

The main advantages of an approach like this is that it usually requires less application logic and the system can make adjustments based on the data usage and system load.

You don't really have to "grab, manipulate, put back" for a session object unless you're replacing the original session object with a completely new instance of that object. Otherwise, you can just locate it and manipulate it. It will remain in the session. The downside of keeping something like a user profile in the session is that it increases the total memory footprint of the session. Use of a lookup/handle approach reduced the memory requirements for the session, although there may be greater or lesser impact on processing speed, depending on whether the object in question is still in cache or has to be re-fetched from the database.


Customer surveys are for companies who didn't pay proper attention to begin with.
Bart Kummel
author
Ranch Hand

Joined: Nov 30, 2007
Posts: 81
Hi Tim,

Excellent analysis, thanks!

Best regards,
Bart
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16145
    
  21

You're welcome! I've been practising this for several years now, so I think I'm doing it pretty well now.
 
jQuery in Action, 2nd edition
 
subject: What is the way to acess same object from different Managed Beans?