Session Objects Approach

[Ayodeji Aladejebi <al...@gmail.com>]

Basically there is an object like this, a common model

class User{
 Long id;
 String username;
 String password;
 String fullname;
 ...
 List collections;
}

>From most examples and basic approach, i see references to this Object in
the session
During user sign in, this object is loaded from database and stored in the
memory and then during authentication, this object is checked against Null
to know if a user is signed in or not and then if required, a getter in the
session returns the reference.


Please correct me if I am wrong,

Now I thought,

Instead of keeping the object reference in the session after a sign in, why
not just keep the ID (Long) and then during authentication, the code just
checks for Null or Zero
 and then if the entire user object is required in any of the pages, The
USER ID is passed into the DAO which then loads the object and then
discarded immediately after use so that no references exists to it again


Does this approach have any significant improvement over the former? and
what could be the cons

Thanks

Re: Session Objects Approach

[Alex Objelean <al...@isdc.ro>]

Take a look on LoadableDetachableModel..


Ayodeji Aladejebi wrote:
> 
> Basically there is an object like this, a common model
> 
> class User{
>  Long id;
>  String username;
>  String password;
>  String fullname;
>  ...
>  List collections;
> }
> 
> From most examples and basic approach, i see references to this Object in
> the session
> During user sign in, this object is loaded from database and stored in the
> memory and then during authentication, this object is checked against Null
> to know if a user is signed in or not and then if required, a getter in
> the
> session returns the reference.
> 
> 
> Please correct me if I am wrong,
> 
> Now I thought,
> 
> Instead of keeping the object reference in the session after a sign in,
> why
> not just keep the ID (Long) and then during authentication, the code just
> checks for Null or Zero
>  and then if the entire user object is required in any of the pages, The
> USER ID is passed into the DAO which then loads the object and then
> discarded immediately after use so that no references exists to it again
> 
> 
> Does this approach have any significant improvement over the former? and
> what could be the cons
> 
> Thanks
> 
> 

-- 
View this message in context: http://www.nabble.com/Session-Objects-Approach-tf4600804.html#a13143236
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Eelco Hillenius <ee...@gmail.com>]

On 10/16/07, Ayodeji Aladejebi <al...@gmail.com> wrote:
> thanks eelco i get your point. deciding what to sacrifice in design whether
> memory or cpu/db traffic is always some challenge for most developers but if
> I dont want my DB crying  then its probably time to buy more RAM

To sum up the whole detachable vs non-detachable models discussion:
sometimes detachable works better and sometimes not - just decide on a
case by case basis :-)

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Matt Jensen <ma...@picasystems.com>]

Just trying to be helpful. :-)


Igor Vaynberg wrote:
> I think what you all are missing in this discussion is that ldms are
> mostly uss for read only data, not for forms.
>
> -igor
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Eelco Hillenius <ee...@gmail.com>]

On 10/16/07, Igor Vaynberg <ig...@gmail.com> wrote:
> I think what you all are missing in this discussion is that ldms are
> mostly uss for read only data, not for forms.

I still don't agree with that. :-) I use ldms in forms myself all the
time. The big catch is that you have to persist changes right away or
you'll loose them. But - save for when you do 'multi step' things,
this is often what you do anyway.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Igor Vaynberg <ig...@gmail.com>]

I think what you all are missing in this discussion is that ldms are
mostly uss for read only data, not for forms.

-igor

On 10/16/07, Matt Jensen <ma...@picasystems.com> wrote:
>
> Another potential gotcha with detachable models is that they can make
> versioning/optimistic locking a bit more difficult to use.  Unless you
> cache the base version of your entity in the detachable model and do
> your own version checking, the typical implementations that I have seen
> will happily reload and overwrite whatever version happens to be in the
> database at the time of a request.  This means, for example, that the
> user might see a form that is initialized with version 1 of your object,
> and then update version 2 if somebody else comes along and makes changes
> before they submit, potentially wiping out the other user's changes.
>
> Obviously, this only affects you if you are versioning your objects.
> It's just a nice tidbit to have in the knowledge base...and again, you
> can design your detachable models around it.  You just end up with a
> little duplication of effort, as Hibernate/JPA/etc. already does this
> for you elsewhere.
>
>
> Ayodeji Aladejebi wrote:
> > thanks eelco i get your point. deciding what to sacrifice in design whether
> > memory or cpu/db traffic is always some challenge for most developers but if
> > I dont want my DB crying  then its probably time to buy more RAM
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Matt Jensen <ma...@picasystems.com>]

Another potential gotcha with detachable models is that they can make 
versioning/optimistic locking a bit more difficult to use.  Unless you 
cache the base version of your entity in the detachable model and do 
your own version checking, the typical implementations that I have seen 
will happily reload and overwrite whatever version happens to be in the 
database at the time of a request.  This means, for example, that the 
user might see a form that is initialized with version 1 of your object, 
and then update version 2 if somebody else comes along and makes changes 
before they submit, potentially wiping out the other user's changes.

Obviously, this only affects you if you are versioning your objects.  
It's just a nice tidbit to have in the knowledge base...and again, you 
can design your detachable models around it.  You just end up with a 
little duplication of effort, as Hibernate/JPA/etc. already does this 
for you elsewhere.


Ayodeji Aladejebi wrote:
> thanks eelco i get your point. deciding what to sacrifice in design whether
> memory or cpu/db traffic is always some challenge for most developers but if
> I dont want my DB crying  then its probably time to buy more RAM
>
>   
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Ayodeji Aladejebi <al...@gmail.com>]

thanks eelco i get your point. deciding what to sacrifice in design whether
memory or cpu/db traffic is always some challenge for most developers but if
I dont want my DB crying  then its probably time to buy more RAM

On 10/16/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > Does this approach have any significant improvement over the former? and
> > what could be the cons
>
> Like Alex said, look at LoadableDetachableModel for instance. You
> don't have to discard right away; just do at at the end of the
> request. It's what detachable is for.
>
> Pro detaching: less memory consumption per session, and you can avoid
> lazy loading problems when you use e.g. Hibernate. Con: more database
> traffic (if you don't cache these objects) and cpu usage (though very
> very minimal). In general a pro is also that your objects are always
> fresh. A general con when working in forms can be that you have to
> persist changes right away or you'll lose them with the reload.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Session Objects Approach

[Eelco Hillenius <ee...@gmail.com>]

> I found another con with detachable is that if you are constructing a complex
> object graph _before_ putting it in the database you would have to do
> something cleverer... e.g. only detach if already persisted? We just stuck
> with non-detachable models.

But the solution to that might be easy: only use the detachable model
on the top object of your complex graph, and let all other models use
that model (opposed to the model object).

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Eelco Hillenius <ee...@gmail.com>]

On 10/16/07, Matej Knopp <ma...@gmail.com> wrote:
> Well, detachable models are mostly used for something you can
> relatively easily reconstruct. If you are building a complex object
> (multi-step wizard etc.) then you don't what to use a detachable
> object for it.

Agreed. Wizards are a good example of where you non-detachable object
often work better.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Matej Knopp <ma...@gmail.com>]

Well, detachable models are mostly used for something you can
relatively easily reconstruct. If you are building a complex object
(multi-step wizard etc.) then you don't what to use a detachable
object for it.

-Matej

On 10/16/07, Sam Hough <sa...@redspr.com> wrote:
>
> I found another con with detachable is that if you are constructing a complex
> object graph _before_ putting it in the database you would have to do
> something cleverer... e.g. only detach if already persisted? We just stuck
> with non-detachable models.
>
>
>
> Eelco Hillenius wrote:
> >
> >> Does this approach have any significant improvement over the former? and
> >> what could be the cons
> >
> > Like Alex said, look at LoadableDetachableModel for instance. You
> > don't have to discard right away; just do at at the end of the
> > request. It's what detachable is for.
> >
> > Pro detaching: less memory consumption per session, and you can avoid
> > lazy loading problems when you use e.g. Hibernate. Con: more database
> > traffic (if you don't cache these objects) and cpu usage (though very
> > very minimal). In general a pro is also that your objects are always
> > fresh. A general con when working in forms can be that you have to
> > persist changes right away or you'll lose them with the reload.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Session-Objects-Approach-tf4600804.html#a13229389
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Sam Hough <sa...@redspr.com>]

I found another con with detachable is that if you are constructing a complex
object graph _before_ putting it in the database you would have to do
something cleverer... e.g. only detach if already persisted? We just stuck
with non-detachable models.



Eelco Hillenius wrote:
> 
>> Does this approach have any significant improvement over the former? and
>> what could be the cons
> 
> Like Alex said, look at LoadableDetachableModel for instance. You
> don't have to discard right away; just do at at the end of the
> request. It's what detachable is for.
> 
> Pro detaching: less memory consumption per session, and you can avoid
> lazy loading problems when you use e.g. Hibernate. Con: more database
> traffic (if you don't cache these objects) and cpu usage (though very
> very minimal). In general a pro is also that your objects are always
> fresh. A general con when working in forms can be that you have to
> persist changes right away or you'll lose them with the reload.
> 
> Eelco
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Session-Objects-Approach-tf4600804.html#a13229389
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Session Objects Approach

[Eelco Hillenius <ee...@gmail.com>]

> Does this approach have any significant improvement over the former? and
> what could be the cons

Like Alex said, look at LoadableDetachableModel for instance. You
don't have to discard right away; just do at at the end of the
request. It's what detachable is for.

Pro detaching: less memory consumption per session, and you can avoid
lazy loading problems when you use e.g. Hibernate. Con: more database
traffic (if you don't cache these objects) and cpu usage (though very
very minimal). In general a pro is also that your objects are always
fresh. A general con when working in forms can be that you have to
persist changes right away or you'll lose them with the reload.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org