Re: Questions about Serialization...

2009-12-09 Thread Yves-Marie LAINÉ
Yes, we are ok, we should put Serializable in session. (But put Serializable
in Session doesn't mean to put Serialized in Session)

And it seems that wicket Serialize each Page one by one. This way if you
have a single object instance that you share between pages as object
property, after pages serialization, if you have ten page referencing your
object you will have ten copies of your object, while you think you have
only one. It's a known serialization drawback. And it's what I want to get
arround, when Serialization is not needed.

I'will look for HttpSesssionStore.

Thanks.

2009/12/8 Marat Radchenko slonopotamusor...@gmail.com

 2009/12/8 Yves-Marie LAINÉ ymla...@gmail.com:
  Hi,
 
  I'm new on the list, sorry if my question has already been asked. I
 didn't
  find the right answer on google.
 
  Is it possible tu use wicket without Page serialization ?
 It is. Use only stateless components.

  Technically, is it possible to imagine a SimpleHttpSessionPageStore that
  don't serialize objects and keep them as they are in session, like it's
 done
  in others frameworks ?
 Logic flaw: session contents CAN get serialized. Read Servlet spec,
 you shouldn't put non-serializable stuff in session.

  But... I'm working on an app that consist of few pages, not versioned (no
  need of the back button support), because I need to keep page state
 through
  navigation, I keep pages references created, avoiding creation of a new
 page
  instance when back on a visited page.. I don't need to write anything on
  disk, the session space is enough.
 Same flaw.

  This way, i wanted to share a data object instance between pages (as
 class
  member), for modification. But due to the Page Serialization the object
  identity is broken.
 That just means your data object serialization is broken.

 Sidenote: you can use HttpSessionStore (instead of
 SecondLevelCacheSessionStore) to make wicket store everything in
 session (but not in it's custom wicket on-disk store)

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




Re: Questions about Serialization...

2009-12-09 Thread Marat Radchenko
2009/12/9 Yves-Marie LAINÉ ymla...@gmail.com:
 (But put Serializable in Session doesn't mean to put Serialized in Session)
Uh?

 And it seems that wicket Serialize each Page one by one. This way if you
 have a single object instance that you share between pages as object
 property, after pages serialization, if you have ten page referencing your
 object you will have ten copies of your object, while you think you have
 only one.
I guess, it just means you use default serialization strategy (you're
using org.apache.wicket.model.Model, aren't you?) but expect it to do
something custom.

 It's a known serialization drawback. And it's what I want to get
 arround, when Serialization is not needed.
Use proper models. For example, HibernateObjectModel from databinder
doesn't serialize whole persistent entity but just its primary key +
class. So on subsequent requests object state is loaded again from db.

Also, I think you skipped one of my points - wicket will _only_
serialize page if there's stateful component on it. It is absolutely
possible to use wicket without any serialization at all (although you
must not use stateful components then). @StatelessComponent from
wicket-devutils is an invaluable tool to enforce such practice.

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



Re: Questions about Serialization...

2009-12-09 Thread Yves-Marie LAINÉ
Thanks you for the advices.

I wasn't using Model in this precise case. I thought using Model was a best
practice, to save memory. Indeed I understand that using Mdel is mandatory,
if you want avoid strange behaviour. IMHO using LoadableDetachableModel is
an extra cost, (cpu, time, design) not necessary for simpler cases.

I did't find out how to desactivate Serialization now, I use statefull
components, but not versioned pages. I don't use new Page() twice for the
same page in my application, I know exactly how many Page instance will be
created, and what is in. So I don't need page serialization to disk...

I will do differently, but I'm a bit sad. Maybe it's possible to create one
page and work with Panel replacement...

Regards

2009/12/9 Marat Radchenko slonopotamusor...@gmail.com

 2009/12/9 Yves-Marie LAINÉ ymla...@gmail.com:
  (But put Serializable in Session doesn't mean to put Serialized in
 Session)
 Uh?

  And it seems that wicket Serialize each Page one by one. This way if you
  have a single object instance that you share between pages as object
  property, after pages serialization, if you have ten page referencing
 your
  object you will have ten copies of your object, while you think you have
  only one.
 I guess, it just means you use default serialization strategy (you're
 using org.apache.wicket.model.Model, aren't you?) but expect it to do
 something custom.

  It's a known serialization drawback. And it's what I want to get
  arround, when Serialization is not needed.
 Use proper models. For example, HibernateObjectModel from databinder
 doesn't serialize whole persistent entity but just its primary key +
 class. So on subsequent requests object state is loaded again from db.

 Also, I think you skipped one of my points - wicket will _only_
 serialize page if there's stateful component on it. It is absolutely
 possible to use wicket without any serialization at all (although you
 must not use stateful components then). @StatelessComponent from
 wicket-devutils is an invaluable tool to enforce such practice.

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




Re: Questions about Serialization...

2009-12-09 Thread Marat Radchenko
  I wasn't using Model in this precise case. I thought using Model was a best
  practice, to save memory.
Choosing proper model isn't (almost always) about performance, it's
about logic. You _have_ to use plain serializing model for data that
isn't stored anywhere else. You _have_ to use LDM in cases when it is
a logical error to operate on outdated data backed by db storage.

 Indeed I understand that using Mdel is mandatory,
  if you want avoid strange behaviour. IMHO using LoadableDetachableModel is
  an extra cost, (cpu, time, design) not necessary for simpler cases.
On the other side, LDM usually reduces page size - allows faster
serilization. But anyway, you decide what model to use based on
application logic requirements. The only choice that is _mostly_
driven by performance conciderations is AbstractReadonlyModel vs. LDM.
But still, sometimes application logic makes it inappropriate to use
LDM since its value has to change during request.

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



Re: Questions about Serialization...

2009-12-09 Thread Lionel Port
Probably the answer to the original question is just use
HttpSessionStore. Its similar issue to when deploying to GAE where you
don't have a disk to serialise to.

regards,
Lionel

On Thu, Dec 10, 2009 at 4:13 AM, Marat Radchenko
slonopotamusor...@gmail.com wrote:
  I wasn't using Model in this precise case. I thought using Model was a best
  practice, to save memory.
 Choosing proper model isn't (almost always) about performance, it's
 about logic. You _have_ to use plain serializing model for data that
 isn't stored anywhere else. You _have_ to use LDM in cases when it is
 a logical error to operate on outdated data backed by db storage.

 Indeed I understand that using Mdel is mandatory,
  if you want avoid strange behaviour. IMHO using LoadableDetachableModel is
  an extra cost, (cpu, time, design) not necessary for simpler cases.
 On the other side, LDM usually reduces page size - allows faster
 serilization. But anyway, you decide what model to use based on
 application logic requirements. The only choice that is _mostly_
 driven by performance conciderations is AbstractReadonlyModel vs. LDM.
 But still, sometimes application logic makes it inappropriate to use
 LDM since its value has to change during request.

 -
 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



Questions about Serialization...

2009-12-08 Thread Yves-Marie LAINÉ
Hi,

I'm new on the list, sorry if my question has already been asked. I didn't
find the right answer on google.

Is it possible tu use wicket without Page serialization ? If no, why ?
Technically, is it possible to imagine a SimpleHttpSessionPageStore that
don't serialize objects and keep them as they are in session, like it's done
in others frameworks ? I know, the main reason is to save Session memory by
writing pages versions on disk... ok.

But... I'm working on an app that consist of few pages, not versioned (no
need of the back button support), because I need to keep page state through
navigation, I keep pages references created, avoiding creation of a new page
instance when back on a visited page.. I don't need to write anything on
disk, the session space is enough.

This way, i wanted to share a data object instance between pages (as class
member), for modification. But due to the Page Serialization the object
identity is broken. My unique data object instance turn into several
instances (As much as pages that references it i guess ...)

I know that I can get arround this by putting directly my object in
session.. But, my question is, why to force serialization when we don't need
it ?

Regards,
Yves-Marie

PS : sorry for my english.


Thanks!


Re: Questions about Serialization...

2009-12-08 Thread Martin Makundi
Where do you keep your data between pages if not in session?

**
Martin

2009/12/8 Yves-Marie LAINÉ ymla...@gmail.com:
 Hi,

 I'm new on the list, sorry if my question has already been asked. I didn't
 find the right answer on google.

 Is it possible tu use wicket without Page serialization ? If no, why ?
 Technically, is it possible to imagine a SimpleHttpSessionPageStore that
 don't serialize objects and keep them as they are in session, like it's done
 in others frameworks ? I know, the main reason is to save Session memory by
 writing pages versions on disk... ok.

 But... I'm working on an app that consist of few pages, not versioned (no
 need of the back button support), because I need to keep page state through
 navigation, I keep pages references created, avoiding creation of a new page
 instance when back on a visited page.. I don't need to write anything on
 disk, the session space is enough.

 This way, i wanted to share a data object instance between pages (as class
 member), for modification. But due to the Page Serialization the object
 identity is broken. My unique data object instance turn into several
 instances (As much as pages that references it i guess ...)

 I know that I can get arround this by putting directly my object in
 session.. But, my question is, why to force serialization when we don't need
 it ?

 Regards,
 Yves-Marie

 PS : sorry for my english.


 Thanks!


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



Re: Questions about Serialization...

2009-12-08 Thread Igor Vaynberg
you can create your own ISessionStore implementation that keeps all
objects in memory.

-igor

2009/12/8 Yves-Marie LAINÉ ymla...@gmail.com:
 Hi,

 I'm new on the list, sorry if my question has already been asked. I didn't
 find the right answer on google.

 Is it possible tu use wicket without Page serialization ? If no, why ?
 Technically, is it possible to imagine a SimpleHttpSessionPageStore that
 don't serialize objects and keep them as they are in session, like it's done
 in others frameworks ? I know, the main reason is to save Session memory by
 writing pages versions on disk... ok.

 But... I'm working on an app that consist of few pages, not versioned (no
 need of the back button support), because I need to keep page state through
 navigation, I keep pages references created, avoiding creation of a new page
 instance when back on a visited page.. I don't need to write anything on
 disk, the session space is enough.

 This way, i wanted to share a data object instance between pages (as class
 member), for modification. But due to the Page Serialization the object
 identity is broken. My unique data object instance turn into several
 instances (As much as pages that references it i guess ...)

 I know that I can get arround this by putting directly my object in
 session.. But, my question is, why to force serialization when we don't need
 it ?

 Regards,
 Yves-Marie

 PS : sorry for my english.


 Thanks!


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



Re: Questions about Serialization...

2009-12-08 Thread Marat Radchenko
2009/12/8 Yves-Marie LAINÉ ymla...@gmail.com:
 Hi,

 I'm new on the list, sorry if my question has already been asked. I didn't
 find the right answer on google.

 Is it possible tu use wicket without Page serialization ?
It is. Use only stateless components.

 Technically, is it possible to imagine a SimpleHttpSessionPageStore that
 don't serialize objects and keep them as they are in session, like it's done
 in others frameworks ?
Logic flaw: session contents CAN get serialized. Read Servlet spec,
you shouldn't put non-serializable stuff in session.

 But... I'm working on an app that consist of few pages, not versioned (no
 need of the back button support), because I need to keep page state through
 navigation, I keep pages references created, avoiding creation of a new page
 instance when back on a visited page.. I don't need to write anything on
 disk, the session space is enough.
Same flaw.

 This way, i wanted to share a data object instance between pages (as class
 member), for modification. But due to the Page Serialization the object
 identity is broken.
That just means your data object serialization is broken.

Sidenote: you can use HttpSessionStore (instead of
SecondLevelCacheSessionStore) to make wicket store everything in
session (but not in it's custom wicket on-disk store)

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