• 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

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

 
Ranch Hand
Posts: 50
jQuery Eclipse IDE Google App Engine
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bart Kummel
author
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tim,

Excellent analysis, thanks!

Best regards,
Bart
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome! I've been practising this for several years now, so I think I'm doing it pretty well now.
 
reply
    Bookmark Topic Watch Topic
  • New Topic