You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by carloc <ca...@yahoo.com> on 2007/09/15 07:48:09 UTC

Question With Detachable Models

Hi, I would like to ask this.

Are my objects still being stored in the session when I use this kind of
query.
I don't requery the objects using a  detachable model.

package com.ccti.web.query;

import org.apache.wicket.model.LoadableDetachableModel;

public class QueryDetachableModel extends LoadableDetachableModel {
	private transient Object instance;
	
	public QueryDetachableModel(Object instance) {
		this.instance = instance;
	}
	@Override
	protected Object load() {
		// TODO Auto-generated method stub
		return instance;
	}

}

Here's how my DataProvider looks like.


public class QueryDataProvider extends SortableDataProvider {
	
	/**
	 * 
	 */
	private transient QueryCommand queryCommand;
	
	public QueryDataProvider(QueryCommand queryCommand) {
		this.queryCommand = queryCommand;
	}

	/* (non-Javadoc)
	 * @see org.apache.wicket.markup.repeater.data.IDataProvider#iterator(int,
int)
	 */
	public Iterator iterator(int first, int count) {
		// TODO Auto-generated method stub

		setQueryLimits(first, count);
		return queryCommand.execute();
	}

	/**
	 * @param first
	 * @param count
	 */
	private void setQueryLimits(int first, int count) {
		// can't be set anywhere else but here.
		queryCommand.setPageIndex(first);
		queryCommand.setPageSize(count);
	}

	public IModel model(Object object) {
		// TODO Auto-generated method stub
		return new QueryDetachableModel(object);
	}

	public int size() {
		// TODO Auto-generated method stub
		return queryCommand.queryCount();
	}
-- 
View this message in context: http://www.nabble.com/Question-With-Detachable-Models-tf4446686.html#a12687511
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: Question With Detachable Models

Posted by Jan Kriesten <ja...@renitence.de>.

> transient fields are never stored in a session at all.

sorry, i meant they are never serialized at all.



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


Re: Question With Detachable Models

Posted by Jan Kriesten <ja...@renitence.de>.
hi,

> Are my objects still being stored in the session when I use this kind of
> query.

transient fields are never stored in a session at all.

but since you have neither an id nor a logic to load your object to be restored,
you certainly will get a NPE when the object is about to be restored.

regards, --- jan.

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


Re: Question With Detachable Models

Posted by Jonathan Locke <jo...@gmail.com>.

we're just quibbling over what "stored in the session" means.  if we mean
(as it seems obvious i did) "is it reachable through the wicket session on
the web node and does it take up memory on that node" then yes it is in some
sense it is "stored in the (wicket) session" (it's there in the debugger and
taking up session-associated resources).  if on the other hand we mean (as
it's obvious you did) "is it is part of the (container) replicated session,
as reconstructed from disk or on other web nodes via serialization" then
it's obviously not "stored in the (container) session" because nothing
transient can ever be serialized by definition.  we were just talking past
each other.


Kent Tong wrote:
> 
> 
> Jonathan Locke wrote:
>> 
>> Your QueryDetachableModel will break under clustering.  The transient
>> "instance" Object will become null when the container deserializes it and
>> your load method will be unable to reload the object.  
>> 
>> If you're using these QueryDetachableModels, yes, the object instance is
>> being stored in your session.  But no, it will not be replicated
>> correctly.
>> 
> 
> Are you sure about that? If the default item reuse strategy is used, new
> models and new items will 
> be created just before the page is rendered.
> 
> In addition, as the object instance is marked as transient, it shouldn't
> be stored in the session.
> 

-- 
View this message in context: http://www.nabble.com/Question-With-Detachable-Models-tf4446686.html#a12697727
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: Question With Detachable Models

Posted by Kent Tong <ke...@cpttm.org.mo>.


Kent Tong wrote:
> 
> Yeah, it is in there because it hasn't been serialized and deserialized.
> 

If your code was like:

public class QueryDetachableModel extends LoadableDetachableModel {
        public QueryDetachableModel(Object instance) {
                super(instance);
        }
        protected Object load() {
                return null;
        }
} 

then your obj should no longer be in the session.
-- 
View this message in context: http://www.nabble.com/Question-With-Detachable-Models-tf4446686.html#a12697331
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: Question With Detachable Models

Posted by Kent Tong <ke...@cpttm.org.mo>.

carloc wrote:
> 
> Somehow, it seems that transient objects are stored in the session.
> WHen I try to look at the session in eclipse's debug mode, 
> I can actually see my User object in there even though I marked as
> transient.
> 

Yeah, it is in there because it hasn't been serialized and deserialized.

-- 
View this message in context: http://www.nabble.com/Question-With-Detachable-Models-tf4446686.html#a12697263
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: Question With Detachable Models

Posted by carloc <ca...@yahoo.com>.
Somehow, it seems that transient objects are stored in the session.
WHen I try to look at the session in eclipse's debug mode, 
I can actually see my User object in there even though I marked as
transient.

I'm not really sure about this behavior though.


Kent Tong wrote:
> 
> 
> Jonathan Locke wrote:
>> 
>> 
>> Your QueryDetachableModel will break under clustering.  The transient
>> "instance" Object will become null when the container deserializes it and
>> your load method will be unable to reload the object.  
>> 
>> If you're using these QueryDetachableModels, yes, the object instance is
>> being stored in your session.  But no, it will not be replicated
>> correctly.
>> 
> 
> Are you sure about that? If the default item reuse strategy is used, new
> models and new items will 
> be created just before the page is rendered.
> 
> In addition, as the object instance is marked as transient, it shouldn't
> be stored in the session.
> 

-- 
View this message in context: http://www.nabble.com/Question-With-Detachable-Models-tf4446686.html#a12696938
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: Question With Detachable Models

Posted by Kent Tong <ke...@cpttm.org.mo>.

Jonathan Locke wrote:
> 
> Your QueryDetachableModel will break under clustering.  The transient
> "instance" Object will become null when the container deserializes it and
> your load method will be unable to reload the object.  
> 
> If you're using these QueryDetachableModels, yes, the object instance is
> being stored in your session.  But no, it will not be replicated
> correctly.
> 

Are you sure about that? If the default item reuse strategy is used, new
models and new items will 
be created just before the page is rendered.

In addition, as the object instance is marked as transient, it shouldn't be
stored in the session.
-- 
View this message in context: http://www.nabble.com/Question-With-Detachable-Models-tf4446686.html#a12696767
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: Question With Detachable Models

Posted by carloc <ca...@yahoo.com>.
Thanks for replying
Yup thanks

I was debugging it and I was able to see it in the session object. meaning
that it is still stored in my object.
I changed the implementation to loading the object.

Now I changed it to loading it from a facade bean.

Thanks


Jonathan Locke wrote:
> 
> 
> I should also add this: although you can do what you will in Wicket, it is
> generally better to use models consistently and reload your objects from
> the DB (this isn't so bad in practice as a lot of the time reloads will
> just hit ehcache or whatever you're using to cache query results and hook
> the object back up again in no time).  It also shrinks the serialization
> overhead and replication bandwidth required to move your objects around in
> the cluster (and with SoftReferenced instance objects it could also
> decrease your non-reclaimable memory load if that matters).  But it is
> also generally helpful to work with reloadable models because they
> automatically avert the more common stale data issues you'll run into.  In
> a multi-user system, this is helpful.  If you've got a Label whose model
> is a PropertyModel on a reloadable PersonModel and someone else changes
> the PersonModel, the expression being retrieved from the model will
> auto-update.  If the label is directly holding the POJO and it's not
> reloadable, the label will continue to display the stale data forever.
> 
> 
> Jonathan Locke wrote:
>> 
>> 
>> Your QueryDetachableModel will break under clustering.  The transient
>> "instance" Object will become null when the container deserializes it and
>> your load method will be unable to reload the object.  
>> 
>> If you're using these QueryDetachableModels, yes, the object instance is
>> being stored in your session.  But no, it will not be replicated
>> correctly.
>> 
>> If you really want to make the memory impact disappear as well as the
>> clustering bandwidth, you would need to use a transient SoftReference and
>> take the hit of implementing a load method which reads your object from
>> some kind of object storage (or cache).
>> 
>> There is no free lunch.  You are ultimately stuck with a tradeoff: either
>> use the memory and/or bandwidth OR be prepared to pay the price of
>> loading the object from storage.
>> 
>> 
>> carloc wrote:
>>> 
>>> Hi, I would like to ask this.
>>> 
>>> Are my objects still being stored in the session when I use this kind of
>>> query.
>>> I don't requery the objects using a  detachable model.
>>> 
>>> package com.ccti.web.query;
>>> 
>>> import org.apache.wicket.model.LoadableDetachableModel;
>>> 
>>> public class QueryDetachableModel extends LoadableDetachableModel {
>>> 	private transient Object instance;
>>> 	
>>> 	public QueryDetachableModel(Object instance) {
>>> 		this.instance = instance;
>>> 	}
>>> 	@Override
>>> 	protected Object load() {
>>> 		// TODO Auto-generated method stub
>>> 		return instance;
>>> 	}
>>> 
>>> }
>>> 
>>> Here's how my DataProvider looks like.
>>> 
>>> 
>>> public class QueryDataProvider extends SortableDataProvider {
>>> 	
>>> 	/**
>>> 	 * 
>>> 	 */
>>> 	private transient QueryCommand queryCommand;
>>> 	
>>> 	public QueryDataProvider(QueryCommand queryCommand) {
>>> 		this.queryCommand = queryCommand;
>>> 	}
>>> 
>>> 	/* (non-Javadoc)
>>> 	 * @see
>>> org.apache.wicket.markup.repeater.data.IDataProvider#iterator(int, int)
>>> 	 */
>>> 	public Iterator iterator(int first, int count) {
>>> 		// TODO Auto-generated method stub
>>> 
>>> 		setQueryLimits(first, count);
>>> 		return queryCommand.execute();
>>> 	}
>>> 
>>> 	/**
>>> 	 * @param first
>>> 	 * @param count
>>> 	 */
>>> 	private void setQueryLimits(int first, int count) {
>>> 		// can't be set anywhere else but here.
>>> 		queryCommand.setPageIndex(first);
>>> 		queryCommand.setPageSize(count);
>>> 	}
>>> 
>>> 	public IModel model(Object object) {
>>> 		// TODO Auto-generated method stub
>>> 		return new QueryDetachableModel(object);
>>> 	}
>>> 
>>> 	public int size() {
>>> 		// TODO Auto-generated method stub
>>> 		return queryCommand.queryCount();
>>> 	}
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Question-With-Detachable-Models-tf4446686.html#a12690353
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: Question With Detachable Models

Posted by Jonathan Locke <jo...@gmail.com>.

I should also add this: although you can do what you will in Wicket, it is
generally better to use models consistently and reload your objects from the
DB (this isn't so bad in practice as a lot of the time reloads will just hit
ehcache or whatever you're using to cache query results and hook the object
back up again in no time).  It also shrinks the serialization overhead and
replication bandwidth required to move your objects around in the cluster
(and with SoftReferenced instance objects it could also decrease your
non-reclaimable memory load if that matters).  But it is also generally
helpful to work with reloadable models because they automatically avert the
more common stale data issues you'll run into.  In a multi-user system, this
is helpful.  If you've got a Label whose model is a PropertyModel on a
reloadable PersonModel and someone else changes the PersonModel, the
expression being retrieved from the model will auto-update.  If the label is
directly holding the POJO and it's not reloadable, the label will continue
to display the stale data forever.


Jonathan Locke wrote:
> 
> 
> Your QueryDetachableModel will break under clustering.  The transient
> "instance" Object will become null when the container deserializes it and
> your load method will be unable to reload the object.  
> 
> If you're using these QueryDetachableModels, yes, the object instance is
> being stored in your session.  But no, it will not be replicated
> correctly.
> 
> If you really want to make the memory impact disappear as well as the
> clustering bandwidth, you would need to use a transient SoftReference and
> take the hit of implementing a load method which reads your object from
> some kind of object storage (or cache).
> 
> There is no free lunch.  You are ultimately stuck with a tradeoff: either
> use the memory and/or bandwidth OR be prepared to pay the price of loading
> the object from storage.
> 
> 
> carloc wrote:
>> 
>> Hi, I would like to ask this.
>> 
>> Are my objects still being stored in the session when I use this kind of
>> query.
>> I don't requery the objects using a  detachable model.
>> 
>> package com.ccti.web.query;
>> 
>> import org.apache.wicket.model.LoadableDetachableModel;
>> 
>> public class QueryDetachableModel extends LoadableDetachableModel {
>> 	private transient Object instance;
>> 	
>> 	public QueryDetachableModel(Object instance) {
>> 		this.instance = instance;
>> 	}
>> 	@Override
>> 	protected Object load() {
>> 		// TODO Auto-generated method stub
>> 		return instance;
>> 	}
>> 
>> }
>> 
>> Here's how my DataProvider looks like.
>> 
>> 
>> public class QueryDataProvider extends SortableDataProvider {
>> 	
>> 	/**
>> 	 * 
>> 	 */
>> 	private transient QueryCommand queryCommand;
>> 	
>> 	public QueryDataProvider(QueryCommand queryCommand) {
>> 		this.queryCommand = queryCommand;
>> 	}
>> 
>> 	/* (non-Javadoc)
>> 	 * @see
>> org.apache.wicket.markup.repeater.data.IDataProvider#iterator(int, int)
>> 	 */
>> 	public Iterator iterator(int first, int count) {
>> 		// TODO Auto-generated method stub
>> 
>> 		setQueryLimits(first, count);
>> 		return queryCommand.execute();
>> 	}
>> 
>> 	/**
>> 	 * @param first
>> 	 * @param count
>> 	 */
>> 	private void setQueryLimits(int first, int count) {
>> 		// can't be set anywhere else but here.
>> 		queryCommand.setPageIndex(first);
>> 		queryCommand.setPageSize(count);
>> 	}
>> 
>> 	public IModel model(Object object) {
>> 		// TODO Auto-generated method stub
>> 		return new QueryDetachableModel(object);
>> 	}
>> 
>> 	public int size() {
>> 		// TODO Auto-generated method stub
>> 		return queryCommand.queryCount();
>> 	}
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Question-With-Detachable-Models-tf4446686.html#a12687727
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: Question With Detachable Models

Posted by Jonathan Locke <jo...@gmail.com>.

Your QueryDetachableModel will break under clustering.  The transient
"instance" Object will become null when the container deserializes it and
your load method will be unable to reload the object.  

If you're using these QueryDetachableModels, yes, the object instance is
being stored in your session.  But no, it will not be replicated correctly.

If you really want to make the memory impact disappear as well as the
clustering bandwidth, you would need to use a transient SoftReference and
take the hit of implementing a load method which reads your object from some
kind of object storage (or cache).

There is no free lunch.  You are ultimately stuck with a tradeoff: either
use the memory and/or bandwidth OR be prepared to pay the price of loading
the object from storage.


carloc wrote:
> 
> Hi, I would like to ask this.
> 
> Are my objects still being stored in the session when I use this kind of
> query.
> I don't requery the objects using a  detachable model.
> 
> package com.ccti.web.query;
> 
> import org.apache.wicket.model.LoadableDetachableModel;
> 
> public class QueryDetachableModel extends LoadableDetachableModel {
> 	private transient Object instance;
> 	
> 	public QueryDetachableModel(Object instance) {
> 		this.instance = instance;
> 	}
> 	@Override
> 	protected Object load() {
> 		// TODO Auto-generated method stub
> 		return instance;
> 	}
> 
> }
> 
> Here's how my DataProvider looks like.
> 
> 
> public class QueryDataProvider extends SortableDataProvider {
> 	
> 	/**
> 	 * 
> 	 */
> 	private transient QueryCommand queryCommand;
> 	
> 	public QueryDataProvider(QueryCommand queryCommand) {
> 		this.queryCommand = queryCommand;
> 	}
> 
> 	/* (non-Javadoc)
> 	 * @see
> org.apache.wicket.markup.repeater.data.IDataProvider#iterator(int, int)
> 	 */
> 	public Iterator iterator(int first, int count) {
> 		// TODO Auto-generated method stub
> 
> 		setQueryLimits(first, count);
> 		return queryCommand.execute();
> 	}
> 
> 	/**
> 	 * @param first
> 	 * @param count
> 	 */
> 	private void setQueryLimits(int first, int count) {
> 		// can't be set anywhere else but here.
> 		queryCommand.setPageIndex(first);
> 		queryCommand.setPageSize(count);
> 	}
> 
> 	public IModel model(Object object) {
> 		// TODO Auto-generated method stub
> 		return new QueryDetachableModel(object);
> 	}
> 
> 	public int size() {
> 		// TODO Auto-generated method stub
> 		return queryCommand.queryCount();
> 	}
> 

-- 
View this message in context: http://www.nabble.com/Question-With-Detachable-Models-tf4446686.html#a12687670
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