In our apps we use a request-scoped guice provider.
This makes the scoping explicit, and as an added benefit you get looser
coupling:
@Inject
Provider<User> userProvider;
When no user is logged in, we return a Null object (which also works
since we use domain driven design extensively).
E.g. User.NONE.
In case we have more complex auth-related context, we inject a
SecurityContext where it's needed.
SecurityContext is a custom class which contains the Provider<User> and
other auth-related functionality.
Op 3-10-2011 17:33, schreef Dan Retzlaff:
Isn't it a bad idea to keep any non-thread-safe objects in the session?
Sharing entities sounds particularly risky since any persistence session
other than the original that, say, tries to initialize a lazy collection
will result in a runtime exception.
Because of this, our application maintains the user primary key in the
Wicket Session (using metadata), but it gets loaded through a RequestCycle
subclass. No need to worry about concurrent access or detach() logic there.
On Mon, Oct 3, 2011 at 1:31 AM, Martin Grigorov<[email protected]>wrote:
On Mon, Oct 3, 2011 at 10:24 AM, Carl-Eric Menzel<[email protected]>
wrote:
On Mon, 3 Oct 2011 01:10:58 -0700 (PDT)
Zeldor<[email protected]> wrote:
But would it be possible to store User data in the session without
having to fetch it from datastore on every request? My users don't
interact with each other and they operate only on their own data. So
it'd be most efficient to store User data in the session and interact
with db only when some data is changed.
Yes, just put a field in your Session and add getter/setter.
This is not good.
This is error prone. This way you'll have to keep the instance in the
Session in sync with the data DB. Additionally the memory size will
increase for no reason. Select by primary key (user id) is fast
operation.
Carl-Eric
www.wicketbuch.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
