jakarta-jcs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Travis Savo <ts...@IFILM.com>
Subject RE: Can the Transient cache store non Serializable objects.
Date Tue, 18 May 2004 17:35:41 GMT
Hey, Antonio.

If I'm not mistaken, it shouldn't be absolutely necessary to have all your
fields be serializable assuming your object implements the Serializable
interface and your not using any persistent or remote caches. The Memory
cache itself doesn't -actually- serialize anything; it only casts them to
the Serializable interface. In practice it's a requirement to have
everything in your object implement the Serializable interface ONLY if your
actually serializing it (like with a disk, remote, or lateral cache). This
is very bad practice, but if your willing to say 'I know it says it's
serializable, and it implements the Serializable interface, but it's really
not' and accept that kludge this may be your easiest option. I repeat, this
is VERY bad form, but most likely you can get away with it.

If you absolutely cannot implement the Serializable interface (either
through composition or extending), it's theoretically possible to change the
interface from Serializable to Object in JCS, assuming your using only
memory caches (no disk, no remote, no lateral), but this is -=highly ill
advised=-. See further suggestions for better altertinatives.

Assuming you need to use a Serializing cache like remote, disk, or lateral: 

You can mark all non serializable fields as 'transient', and have the object
implement a 'restoreState()' feature which resets the value of those fields,
which YOU call every time you get the object out of cache. 'restoreState()'
would ensure that none of those fields are null. Marking them transient
tells the Serializer not to serialize them.

Taking the above suggestion a step further, you could implement the Memento
pattern where a separate object which -can- be serialized contains the logic
necessary to capture the state of your entity in a serializable way, and
recreate it on demand. An 'I'm Feeling Lucky' Google pointed me here:
http://www.dofactory.com/patterns/PatternMemento.aspx but further searches
will reveal many more references I'm sure. Then you simply cache the
Mementos. If your clever you'll wrap this in a Bridge or Adapter and save
yourself the trouble of making/restoring from Mementos throughout your code.
This, or the restoreState() solution is probably the one I'd implement
myself, but all reasonable disclaimers apply: I am not an OO design God,
your mileage may vary, use this advice at your own peril, other solutions
may suit your needs better, I take no responsibility for your code or design
decisions, implementation is left as an exercise to the reader, yadda yadda
yadda, blah blah blah.

Hope this helps.

-Travis Savo <tsavo@ifilm.com>

-----Original Message-----
From: Antonio Gallardo [mailto:agallardo@agssa.net]
Sent: Monday, May 17, 2004 6:04 AM
To: turbine-jcs-dev@jakarta.apache.org
Subject: Can the Transient cache store non Serializable objects.


We are testing at Cocoon JCS. The actual tests are running well. But we
have a question:

Is posible to store in the Transient cache non-Serializable objects? We
noted that o.a.jcs.access.CacheAccess.put() serialize the content of the
Object. We needed to change an Object to allow it work with JCS:


But now we have a problem:

The class in question contains:

1)    private Logger logger; /* from AbstractLogEnabled */
2)    private SourceResolver resolver;
3)    private String systemId;
4)    protected Map namespaceURIs = new HashMap();
5)    private ServiceManager manager;

While 3 and 4 are Serializable, the rest is not. Now, please explain how
fields 1, 2, and 5 will be de-serialized. We know the default Java
behavior in this scenario is: they will be null. Next, imaging how those
XSP pages we are testing will work when 1,2, and 5 are null.

This problem is crucial for us. Please explain about that.

Best Regards,

Antonio Gallardo

To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org

To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org

View raw message