Hi Les,
Great explanation! Thank you for taking the time to respond, very much
appreciated. Burning those key points into my system.
Going forward, will keep the session objects light weight using
pointers/referenceId's. I tried placing that in the
subject.getSession().setAttribute("longId", longInstance);
and later accessed it without any issues.That was nice and simple.
Something I like to confirm: The subject.getSession() is an application
scope isn't it? I guess it is coz the subject is available in the session
until he his logged out.
"But be sure to read the Subject#getPrincipal JavaDoc to understand how it
works - especially if you have multiple realms in your application."
On the above point you made, I had a read of the JavaDocs and I guess what
you were pointing me to was using an application wide unique
identifier(uniqueness)? If possible can you explain what the implications
are across multiple realms in this context please?
Regarding performance, I need to look at how to enable caching because I use
Hibernate and sometimes lookup LDAP as well. If I don't hit the datasources
often using
the cache mechanism that will be great. Thanks for pointing out again.
Many Thanks
Niv
On Fri, Jul 30, 2010 at 7:58 AM, Les Hazlewood-2 [via Shiro User] <
[email protected]<ml-node%[email protected]>
> wrote:
> Hi Niv,
>
> You typically don't want to store complete domain objects (UserVO or
> otherwise) in the PrincipalCollection or return them in the
> AuthenticationInfo. The Subject's principals at runtime are intended
> to be very lightweight identifying attributes that act as 'pointers'
> to the complete data set. For example, an ideal principal would be a
> user table primary key value (e.g. a long), or a UUID, or username -
> essentially anything that would allow you to lookup the more complete
> data set at runtime.
>
> So, you would acquire the principal (for example, if the principal was
> a user table rdbms primary key):
>
> Long userId = (Long)subject.getPrincipal();
> //get the User object:
> User user = userService.getUser(userId);
>
> where 'userService' is your own application's mechanism for performing
> User CRUD operations and other business logic. But be sure to read
> the Subject#getPrincipal JavaDoc to understand how it works -
> especially if you have multiple realms in your application.
>
> As for storing things in the session, that's really easy:
>
> subject.getSession().setAttribute(myKey, myValue);
>
> and then retrieve it any time later:
>
> myValue = (myValueType)subject.getSession().getAttribute(myKey);
>
> Be careful with storing things in the session though - your system
> won't scale very well if you add a lot of data to the session: the
> more session data there is, the more the session management mechanism
> needs to store/retrieve data and the more work it has to do. The
> problem is greatly exacerbated when session clustering is enabled -
> you have much more data to send across the network connection, which
> can be much slower.
>
> But these session best practices are not because of Shiro's design or
> implementation - all session management mechanisms, such as serlvet
> containers like Tomcat, Jetty or JEE servers, experience the same
> problem. You typically want your sessions to be as lightweight as
> possible where they only contain 'pointer' fields that allow you to
> lookup the more complete information at runtime. So in the
> subject.getSession().setAttribute call, try to keep 'myValue'
> something like a long ID or String or something that can be used for
> lookup later.
>
> The key to performance and scalability for all of these 'pointer'
> scenarios is based on how your Service (and/or DAO) implementations
> work - typically utilizing 1st and 2nd-level caching for things like
> JPA or Hiberate is a good idea to ensure that the User lookups at
> runtime can be as fast as possible and not 'hit' your datastore every
> time. Each application is different - architect accordingly.
>
> HTH,
>
> Les Hazlewood
> Katasoft, Inc.
> http://www.katasoft.com <http://www.katasoft.com?by-user=t>
>
> On Tue, Jul 27, 2010 at 8:08 PM, nivs <[hidden
> email]<http://user/SendEmail.jtp?type=node&node=5352466&i=0>>
> wrote:
>
> >
> > Hi
> >
> > I looked around for posts on user and session. I could not find anything
> > particular to what I want, so do bear with me if it sounds familiar and
> has
> > been answered.
> >
> > Scenario:User Logs in:
> > User is authenticated and the user/subject is placed into Shiro's session
> in
> > the following way..
> >
> > new SimpleAuthenticationInfo(userVO.getUserName(),
> > userVO.getPassword(),getName());(In the Realm)
> >
> > Post Login:
> >
> > 1. User does a search for things, selects an item from a list.
> >
> > What I want to achieve onSelection of the thing is:
> >
> > 1. To load the item user had selected and associate it with the subject
> in
> > session.
> > 2. To access the subject's principal and get access to this object/item
> that
> > was added in Step 1.
> >
> > In regard to SimpleAuthenticationInfo, will I be able to store the UserVO
>
> > object instance itself? That way I would have this 'thing' item as a
> member
> > of the UserVO?
> >
> > Thank you for the time.
> > Niv
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://shiro-user.582556.n2.nabble.com/How-to-associate-objects-with-subject-s-session-tp5345015p5345015.html<http://shiro-user.582556.n2.nabble.com/How-to-associate-objects-with-subject-s-session-tp5345015p5345015.html?by-user=t>
> > Sent from the Shiro User mailing list archive at Nabble.com.
>
>
> ------------------------------
> View message @
> http://shiro-user.582556.n2.nabble.com/How-to-associate-objects-with-subject-s-session-tp5345015p5352466.html
> To unsubscribe from How to associate objects with subject's session?, click
> here<http://shiro-user.582556.n2.nabble.com/subscriptions/Unsubscribe.jtp?code=c2hyYXZhbm5pdmVAZ21haWwuY29tfDUzNDUwMTV8LTk3Mzc5NzgyNg==>.
>
>
>
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/How-to-associate-objects-with-subject-s-session-tp5345015p5353665.html
Sent from the Shiro User mailing list archive at Nabble.com.
