Re: Questions about Serialization...
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/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...
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...
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...
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
Re: Questions about Serialization...
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...
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/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
