jakarta-jcs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Can the Transient cache store non Serializable objects.
Date Wed, 19 May 2004 07:14:33 GMT
Hi,

our use case is a little bit different. We wanted to use JCS
as a transient (only in-memory) store. So, the objects we
store do not have to be serializable. 

Yes, we could fake the objects and pretend them to be serializable,
but this is the least option we want to take :)
I think, as the JCS interface does use "Object" and not "Serializable"
it's valid to put a not serializable object into JCS. The cast
to serializable should only happen if it is really required.
So changing the behaviour of JCS would be great! :)

If you think that this doesn't make sense than I think you should
change the JCS interfaces from "Object" to "Serializable" to
explicitly state that the data has to be Serializable.

WDYT?

Carsten
 

> -----Original Message-----
> From: Travis Savo [mailto:tsavo@IFILM.com] 
> Sent: Tuesday, May 18, 2004 7:36 PM
> To: 'Turbine JCS Developers List'
> Subject: RE: Can the Transient cache store non Serializable objects.
> 
> 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.
> 
> 
> Hi:
> 
> 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:
> 
> http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=108479287011928&w=2
> 
> 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
> 
> 


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


Mime
View raw message