• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Implement Serializable judiciously?

 
Ranch Hand
Posts: 751
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All my beans implement the interface Serializable. Though I am not sure about the saying

"Stateful workaround in a stateless Protocol"

I just implemented it without really knowing the danger/benefits. We're still in the early process of our development and removing it wouldn't do much trouble. What do you guys thing? Thank you!
[ November 02, 2006: Message edited by: Bear Bibeault ]
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The protocol used is a stateless protocol(ex: Http) which cannot maintain the state between the client and server. Its the developer who has to take care of the session. There are few APIs available as well which helps in maintaining the sessions across the client and the server. Your bean is implemnting serializable, so that you can save the state of the object, which has got nothing do with the protocol. (Serialization itself uses soem protocol to save the state which is out of the scope). so you make sure that your beans are served properly and shared across the valid clients. If you are not maintaining sessions acress the clients, chances are there that different clients may be served with the different beans
 
Prasad Prabhu
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Implement the serializable if you are planning to save the state of the objects (beans) or else dont implement it. Although it is a marker interface (which doesnt contain any methods) its still a overhead.

Hope i cleared your doubt
 
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you know that your beens would never be serialized then why do you want to make those serializable.If you want to store those bean in session then also you do not need to serialize unless you deploy your application in cluster.where there might be a need of travel for the beans.
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Servlets/JSPs don't need to serialize any of your objects to communicate with a browser. Your session, request, context, and page objects live only on the server.

There are times however when a container will want to serialize your session scoped variables. Tomcat, for instance, uses serialization to preserve sessions over webapp reloads and server restarts. Also, if you are using clustering, Tomcat will serialize your session data in order to replicate it on each of your cluster nodes.
Other containers behave similarly.

For this reason, it is a good idea to make sure that any object you bind to session implements serializable. Also, make sure that any object contained by a session scope object implements serializable. Most of the collection objects provided by Java implement serializable but things like Iterator, file handles, ResultSets, etc, can not be made serializable. If you try to store one of these things in session, the container will not be able to serialize your sessions and you will loose features like session replication, and the ability to persist sessions across application restarts.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic