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?
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.
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.
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.)
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.
An IDE is no substitute for an Intelligent Developer.