class mydataprovider implements idataprovider {
private transient list cache;
private list getresult() {
if (cache==null) {
// load the list from db;
cache=list;
} return cache;
}
public iterator iterator() { return getresult().iterator(); }
public int size() { return getresult().size(); }
public void detach() { cache=null; }
}
-igor
On Thu, Nov 5, 2009 at 8:25 PM, <b...@actrix.gen.nz> wrote:
> Igor,
>
> Creating the list of entities exclusively inside iterator() requires
> two database calls for retrieving a list for a single request, the
> additional call being required for the size() method that is called
> prior to iterator(). That is an unfortunate side effect of this API.
>
> I don't have a problem with that as I work around it, as others have
> done before me, by fetching the data eagerly with the size() method
> and then caching it in a volatile field for use by iterator().
>
> I just can't afford to make two database calls.
>
> So I wonder, what is the situation with SerializableChecker
> complaining about that volatile field not being Serializable. Is this
> a bug or do I miss anything?
>
> Should I use something else instead of IDataProvider?
>
> Many thanks.
>
> Bernard
>
>
> On Thu, 5 Nov 2009 20:05:37 -0800, you wrote:
>
>>you should create the list of entities inside iterator() call, not
>>hold on to it in a field. see the phonebook example.
>>
>>-igor
>>
>>On Thu, Nov 5, 2009 at 7:06 PM, <b...@actrix.gen.nz> wrote:
>>> Thanks again Igor.
>>>
>>> I have switched to plain IDataProvider as suggested, although I have
>>> to admit that I still have to look at the phonebook example.
>>>
>>> Again, IDataProvider is an improvement, but still not good.
>>>
>>> It appears that SerializableChecker is complaining about a volatile
>>> field not being Serializable. Is this a bug or do I miss anything?
>>>
>>> I think that SerializableChecker is a wondeful tool, that is why I am
>>> persevering:
>>>
>>> org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
>>> Unable to serialize class: MyEntity
>>>
>>> ...
>>> private volatile java.util.List MyEntityDataProvider.entities
>>> [class=java.util.Vector]
>>>
>>> ...
>>>
>>>
>>> public class MyEntityDataProvider implements IDataProvider<MyEntity>{
>>>
>>> private final Integer searchId;
>>> private volatile List<MyEntity> entities;
>>>
>>> public MyEntityDataProvider(Integer searchId) {
>>> this(searchId, null);
>>> }
>>>
>>> public MyEntityDataProvider(Integer searchId, List<MyEntity>
>>> entities) {
>>> this.searchId = searchId;
>>> this.entities = entities;
>>> }
>>>
>>> �...@override
>>> public Iterator<MyEntity> iterator(int first, int count)
>>> {
>>> return entities.iterator();
>>> }
>>>
>>> �...@override
>>> public int size()
>>> {
>>> if(this.entities == null){
>>> SessionLocal sessionBean = MyApplication.getSessionBean();
>>> this.entities = sessionBean.getMyEntities(this.searchId);
>>> }
>>> return this.entities.size();
>>> }
>>>
>>> �...@override
>>> public IModel<MyEntity> model(MyEntity entity)
>>> {
>>> return new DetachableMyEntityModel(entity);
>>> }
>>>
>>> �...@override
>>> public void detach()
>>> {
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>
>>> On Thu, 5 Nov 2009 18:30:20 -0800, you wrote:
>>>
>>>>no, you should not be using listdataprovider, it is only for static
>>>>lists of things.
>>>>
>>>>if you want best practice look at the phonebook example in wicket-stuff.
>>>>
>>>>-igor
>>>>
>>>>On Thu, Nov 5, 2009 at 5:52 PM, <b...@actrix.gen.nz> wrote:
>>>>> Igor,
>>>>>
>>>>> Thanks very much for your suggestion which I followed.
>>>>>
>>>>> I have overridden it and that is an improvement but still not good.
>>>>>
>>>>> ListDataProvider dataProvider = new ListDataProvider(myList){
>>>>> �...@override
>>>>> public IModel<MyEntity> model(Object object)
>>>>> {
>>>>> return new DetachableMyEntityModel((MyEntity) object);
>>>>> }
>>>>> };
>>>>>
>>>>> SerializableChecker does a nice job spotting:
>>>>>
>>>>> ...
>>>>> private final java.util.List
>>>>> org.apache.wicket.markup.repeater.data.ListDataProvider.list[write:1]
>>>>> [class=[Ljava.lang.Object;]
>>>>>
>>>>> private final java.util.List
>>>>> org.apache.wicket.markup.repeater.data.ListDataProvider.list[write:1][0]
>>>>> [class=MyEntity] <----- field that is not serializable
>>>>>
>>>>> I guess that private final List<T> list; of ListDataProvider wants to
>>>>> be serialized into the session which we don't want?
>>>>>
>>>>> I am trying to apply best practice - may be I should not be using
>>>>> ListDataProvider?
>>>>>
>>>>> http://old.nabble.com/How-to-avoid-Lazy-loading-exception-td17040941.html
>>>>>
>>>>> "instead of using listdataprovider you should use a dataprovider in
>>>>> that uses detachablemodels for each individual item -igor "
>>>>>
>>>>> Today, with 1.4, what is best to use for <List> results from
>>>>> EntityManager? Still DataProvider?
>>>>>
>>>>> Many thanks,
>>>>>
>>>>> Bernard
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 5 Nov 2009 14:25:01 -0800, you wrote:
>>>>>
>>>>>>you have to override listdataprovider#model and return a detachable model.
>>>>>>
>>>>>>-igor
>>>>>>
>>>>>>On Thu, Nov 5, 2009 at 2:19 PM, <b...@actrix.gen.nz> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am trying to prevent the leaking of business objects into the
>>>>>>> session.
>>>>>>>
>>>>>>> Michael made a good comment in
>>>>>>>
>>>>>>> http://www.mail-archive.com/users@wicket.apache.org/msg31187.html
>>>>>>>
>>>>>>> "... you could e.g. temporarily remove the "Serializable" from your
>>>>>>> model-classes and go spotting nonserializable exceptions until they
>>>>>>> don't ocurr anymore."
>>>>>>>
>>>>>>> which is what I did.
>>>>>>>
>>>>>>> It works nicely until I hit a problem with ListDataProvider in
>>>>>>> DataView, where I get an exception even if I use LDMs:
>>>>>>>
>>>>>>> java.lang.ClassCastException: MyEntyty cannot be cast to
>>>>>>> java.io.Serializable at
>>>>>>> org.apache.wicket.markup.repeater.data.ListDataProvider.model(ListDataProvider.java:35)
>>>>>>>
>>>>>>> It appears to me that the approach has a conflict with framework
>>>>>>> classes.
>>>>>>>
>>>>>>> What is the best way to spot session memory issues without hitting
>>>>>>> this problem?
>>>>>>>
>>>>>>> Many thanks,
>>>>>>>
>>>>>>> Bernard
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>For additional commands, e-mail: users-h...@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
