CODEWITHSUNDEEP
javaserializationwicket
user2509111
user2509111

Reputation: 23

What happens in a clustered wicket environment when a model object is not serializable?

I'm seeing a NotSerializableException in the logs for a few of our model objects and I know that the fix for this is to make them serializable, but we are also seeing MarkupExceptions about components not being added to the page and I'm wondering if this could be related. We're only seeing the errors in production where clustering is turned on.

So my question is, what happens when a model object is not serializable, even if all it's attributes are serializable?

Upvotes: 0

Views: 402

Answers (1)

Nigel Sheridan-Smith
Nigel Sheridan-Smith

Reputation: 775

As far as I know, if you do not declare a class as serializable, then it will be missing from the serialized version on the subsequent actions (e.g. form submissions, behaviour, AJAX). Consequently, when the object is deserialized, it is likely that any object references will be null if child object cannot successfully be reloaded from the storage.

You should definitely avoid serializing objects unnecessarily. This includes in response to AJAX requests.

Best practices dictate:

  1. Store only the minimum serialized objects required

    • Avoid declaring variables 'final' and referencing these from anonymous inner classes
    • Avoid having too many objects stored as fields in serialized objects (pages, panels or lists, etc)

  2. Load objects for each request - especially model objects, which should be loaded from your data repository as each request is processed

  3. Load your data objects outside of the constructor

  4. Use models for all data, and attempt to mirror the Wicket structure for simplicity (e.g. using CompoundPropertyModel, where fields are loaded from the model object using reflection, based on the wicket:id used)

  5. Use detachable models for any large objects that are loaded

  6. Avoid using anonymous inner classes too much - use proper event handlers so your code is easier to read and maintain.

I have been working on a complex Wicket application for some time and I can tell you that you want to avoid duplicate objects appearing due to overuse of serialization / deserialization - it can be a nightmare to debug and fix.

Have a read of these for more information / suggestions:

http://letsgetdugg.com/2009/04/19/wicket-anti-patterns-avoiding-session-bloat/ https://cwiki.apache.org/confluence/display/WICKET/Best+Practices+and+Gotchas

Upvotes: 1

Related Questions