Transactions with RuntimeException

[slowery23]

We have a filter that runs in our context before the wicket filter that
starts a hibernate transaction, does a chain.doFilter() and then commits the
transaction.  The problem we are running into is that if a RuntimeException
is thrown, Wicket catches it, logs it and figures out which page to display
to the user.  However, the exception is swallowed and therefore our filter
has no knowledge that something bad occurred and is committing the
transaction when it shouldn't be.

What is the recommended way to deal with this?

[Pedro H. O. dos Santos]

Here at work we abandon this strategy, and create the transaction for
service.

On Thu, Nov 5, 2009 at 5:20 PM, Steve Lowery <slowery@...>wrote:

> We have a filter that runs in our context before the wicket filter that
> starts a hibernate transaction, does a chain.doFilter() and then commits
> the
> transaction.  The problem we are running into is that if a RuntimeException
> is thrown, Wicket catches it, logs it and figures out which page to display
> to the user.  However, the exception is swallowed and therefore our filter
> has no knowledge that something bad occurred and is committing the
> transaction when it shouldn't be.
>
> What is the recommended way to deal with this?
>

--
Pedro Henrique Oliveira dos Santos

[Pedro H. O. dos Santos]

(...)transaction per service.

On Thu, Nov 5, 2009 at 5:33 PM, Pedro Santos <pedrosans@...> wrote:

> Here at work we abandon this strategy, and create the transaction for
> service.
>
>
> On Thu, Nov 5, 2009 at 5:20 PM, Steve Lowery <slowery@...>wrote:
>
>> We have a filter that runs in our context before the wicket filter that
>> starts a hibernate transaction, does a chain.doFilter() and then commits
>> the
>> transaction.  The problem we are running into is that if a
>> RuntimeException
>> is thrown, Wicket catches it, logs it and figures out which page to
>> display
>> to the user.  However, the exception is swallowed and therefore our filter
>> has no knowledge that something bad occurred and is committing the
>> transaction when it shouldn't be.
>>
>> What is the recommended way to deal with this?
>>
>
>
>
> --
> Pedro Henrique Oliveira dos Santos
>

--
Pedro Henrique Oliveira dos Santos

[igor.vaynberg]

check the http response code?

-igor

On Thu, Nov 5, 2009 at 11:20 AM, Steve Lowery
<slowery@...> wrote:

> We have a filter that runs in our context before the wicket filter that
> starts a hibernate transaction, does a chain.doFilter() and then commits the
> transaction.  The problem we are running into is that if a RuntimeException
> is thrown, Wicket catches it, logs it and figures out which page to display
> to the user.  However, the exception is swallowed and therefore our filter
> has no knowledge that something bad occurred and is committing the
> transaction when it shouldn't be.
>
> What is the recommended way to deal with this?
>

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

[igor.vaynberg]

another common approach is to do this

have your txn filter put a transaction handle into a threadlocal, then
in requestcycle.onruntimeexception() you can do :
transactionholder.gettransaction().setrollbackonly(true);

-igor

On Thu, Nov 5, 2009 at 11:59 AM, Igor Vaynberg <igor.vaynberg@...> wrote:

> check the http response code?
>
> -igor
>
> On Thu, Nov 5, 2009 at 11:20 AM, Steve Lowery
> <slowery@...> wrote:
>> We have a filter that runs in our context before the wicket filter that
>> starts a hibernate transaction, does a chain.doFilter() and then commits the
>> transaction.  The problem we are running into is that if a RuntimeException
>> is thrown, Wicket catches it, logs it and figures out which page to display
>> to the user.  However, the exception is swallowed and therefore our filter
>> has no knowledge that something bad occurred and is committing the
>> transaction when it shouldn't be.
>>
>> What is the recommended way to deal with this?
>>
>

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

[bht]

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@.../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-unsubscribe@...
For additional commands, e-mail: users-help@...

[igor.vaynberg]

you have to override listdataprovider#model and return a detachable model.

-igor

On Thu, Nov 5, 2009 at 2:19 PM,  <bht@...> 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@.../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-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[bht]

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,  <bht@...> 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@.../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-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@...
>For additional commands, e-mail: users-help@...

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

[igor.vaynberg]

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,  <bht@...> 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,  <bht@...> 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@.../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-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@...
>>For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[Joe-246]

I  have a panel in the top part of my page. This panel  contain  a login form. But,
I don't login with the panel  because I have  been on the page for too long(session timeout)
also i have a login page , the page contain a login form .But when session timeout , it can login
 the two State's  backcode is same. but i found the panel code don't
call submit methods when session timeout Why does such things could happen.
 


      ___________________________________________________________
  好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/

[bht]

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,  <bht@...> 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,  <bht@...> 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@.../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-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@...
>>>For additional commands, e-mail: users-help@...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@...
>For additional commands, e-mail: users-help@...

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

[igor.vaynberg]

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,  <bht@...> 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,  <bht@...> 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,  <bht@...> 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@.../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-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscribe@...
>>>>For additional commands, e-mail: users-help@...
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@...
>>For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[igor.vaynberg]

the panel is in a page, the page is in session. if the session timed
out the panel no longer exists.

you should use a StatelessForm for things like login panels.

-igor

On Thu, Nov 5, 2009 at 6:36 PM, Joe <huanghuahe@...> wrote:

> I  have a panel in the top part of my page. This panel  contain  a login form. But,
> I don't login with the panel  because I have  been on the page for too long(session timeout)
> also i have a login page , the page contain a login form .But when session timeout , it can login
>  the two State's  backcode is same. but i found the panel code don't
> call submit methods when session timeout Why does such things could happen.
>
>
>
>      ___________________________________________________________
>  好玩贺卡等你发，邮箱贺卡全新上线！
> http://card.mail.cn.yahoo.com/

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

[bht]

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,  <bht@...> 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,  <bht@...> 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,  <bht@...> 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@.../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-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: users-unsubscribe@...
>>>>>For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@...
>>>For additional commands, e-mail: users-help@...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@...
>For additional commands, e-mail: users-help@...

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

[James Carman-3]

Are you always retrieving the entire list?

On Thu, Nov 5, 2009 at 11:25 PM,  <bht@...> 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,  <bht@...> 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,  <bht@...> 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,  <bht@...> 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@.../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-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscribe@...
>>>>For additional commands, e-mail: users-help@...
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@...
>>For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[bht]

Hi James,

Thanks for the question.

In this case, yes. In other cases where I use IDataProvider, no.
I know that IDataProvider provides functionality for pagination which
I don't use here, that is why I ignored it.

I must admit I have a few issues with IDataProvider but I don't want
to distract from the original issue.

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?

I just want to retrieve a list from the database, display it in a
table while not having to deal with fake Serializable issues when I
remove the Serializable interface from the business object. I have to
do this to check the application for leaks of that business object
into the session.

Many thanks.



Bernard


On Thu, 5 Nov 2009 23:29:02 -0500, you wrote:

>Are you always retrieving the entire list?

[snip]


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

[mbrictson]

I think the problem is that you are using the "volatile" keyword when you should be using "transient".

bht wrote:

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?

[igor.vaynberg]

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,  <bht@...> 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,  <bht@...> 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,  <bht@...> 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,  <bht@...> 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@.../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-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscribe@...
>>>>For additional commands, e-mail: users-help@...
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@...
>>For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[bht]

Thanks very much!

As pointed out, I was incorrectly using the keyword volatile instead
of transient. All is well now with IDataProvider and
SerializableChecker.

SerializableChecker is great!

Bernard

On Thu, 5 Nov 2009 22:30:59 -0800, you wrote:

>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

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