A lot of projects I saw always put objects in Session context in order to avoid reload from the DB in the next request, by example for an edit page. I was thinking to provide methods to serializable+url encode objects in a hidden field. This way, We could transfer an object from request to request easily.
- No more session, so less memory use.
- No more reload from database.
- No more interference between two pages in the same explorer.
- The object is drop as soon as Im no more in my page.
- Serialization is long.
- My page will be heavier.
- The object is drop as soon as Im no more in my page (also bad).
Any comment on this (small) pattern?
Couple of things to note here, first thing is, I am now in a position to manipulate your bytestream. Anything that winds up at the client, must become untrusted to a certain degree. Second thing is character encoding, the way a given stream of bytes if returned by a browser may be affected by a char encoding setting.
I would say, take the memory hit, or break your object down into more primitive objects and see if you can't get the size down.
Agreed. A good example is using a Calendar object in your session takes a lot more memory than a Date object, or the primitive int extracted from the int.
Also, make sure you are using a shallow object graph, as reconstituting those links is expensive.
If you want to know how much you are storing, you could serialize the session to a bytestream, and see how many bytes are written.
A last note would be that you might be able to cache your data in a singleton on the server side, if the data applies to more than one user. Make sure to use a MRU mechanism to clear it out, if the data applies across users.
Scott, Max and fsdg (most difficult to pronounce ;)
I guess the problem is fairly treated with struts framework. With struts you anyway have a form bean with scope options of session, request, document. This way the problem of session storage and page-to-page reference is solved. Secondly struts have many added advantages that help us to segregate server side code and client side code. Struts is a beauty with dynamic data exchange through introspection.
Why reinvent the wheel when there is a whole community working on solving the big problem.
Yes, I forgot to speak about the security problem. It's not a big deal IMHO since in framework like Struts, setter are call without control, so, you should never trust the object it gives you.
The character encoding is not a problem if you URLEncode the stream as I suggest.
This pattern is, of course, for small object or small list.
Struts give you the choice of the context, not a new context. My pattern is made to avoid having to much hidden file and avoid having to reconstruct the object by ourself. And it's only if you don't want to put object in session because of the risk of interference.