See my response. :)We just moved to ehcache here; I wasn't happy with OSCache performance or semantics; I'll look at changing back to it if/when they release OSCache 3.0, which is intended to get rid of the exception-throws on cache miss or cache expired, and the resulting synchronization they implement (it's just not appropriate in our environment)
As for FKCache... Ugh. What a mess. Which version is the API built against? They're in the middle of changing their API implementation, and the current TOT's lost total control over programmatically building caches, which I'm not keen on.
IMO: Mark FKCache as being based on an API seriously in flux in documentation - I suspect the API is going to continue to go under radical change, if indeed it ever gets updated; in its current state, it's a mess.
OSCache is a good solid cache API, and JCS may be slow but it is relatively common. Neither of them, however, are used in my environment - I've just moved our local implementation of the expiration system to the ehcache build.
(Which reminds me, I need to get around to building a hashbelt implementation of our existing cache API for those who want a faster cache that doesn't rely on external libs)
On 1 Aug 2005, at 10:55, Werner Guttmann wrote:
Greg,if you could still ctrl-1 through some of these couurences, that would be great. I agree on the subject of the generated classes, so let's create a new issue at http://jira.codehaus.org/browse/CASTOR and let#s assign it to the XML sub-project.Thanks Werner PS Speaking of which, fancy testing some distributed caches ... ;-) ? -----Ursprüngliche Nachricht----- Von: Gregory Block [mailto:[EMAIL PROTECTED] Gesendet: Montag, 01. August 2005 11:36 An: [email protected]Betreff: Re: [castor-user] Missing serialVersionUID in Castor generatedclasses? Yeah, at some point, I'll go through andn cmd-1 some UIDs into those in Eclipse; won't really solve the big problem, tho, which is that Castor's own classes should (IMO) generate code that obeys the basic rules for UIDs in classes - that two classes which serialize to the same representation should have the same UID, to ensure that serialized versions can be loaded in. That's going to become a *lot* more valuable once people start using serializable caches, and people start trying to upgrade live applications running distributed caching, possibly with persistent disk caches, on their live services - who may suddenly find that the entire live service contains a set of cached information which simply isn't readable anymore for no reason other than that they simply recompiled their app. On 26 Jul 2005, at 20:38, Werner Guttmann wrote:Greg, I wasn't particularly referring to generated classes per se. It just occurred to me - when replying - that there actually is a lot of classes out there in src codebase that are Serializable, but don't carry a UID. Werner On Tue, 26 Jul 2005 12:25:16 +0100, Gregory Block wrote:In the code generator? I'm not so keen on changing things I don't actually use in my projects - and code generation pretty much falls at the bottom of the list of things I might ever want to use. :) Code generator *should* generate UIDs; that it does not is no betteror worse than generating code that generates lots of warnings... butin order for Code Generator to generate those UIDs, there's one fundamental question worth asking: Should CG always generate the same UID for a given list of fields, types, and orders? In other words, should re-generating the exact same schema result in the same UIDs? If people have a build process that involves every clean build in completely re-generating those classes, then they will essentially break their own serialization with every major version. Answer, IMO: YES. This means that UID generation won't resemble Java's own mechanism, but will generate a long based on (probably) a hash of the class name, package name, field member types, and field names, in order. Changes which would not result in a change to the hash will not get recognized; this would, however, mean that UIDs will be based on the actual fields present in the XML, and XML changes will auto-modify the UID to break serialization on that class. Downside: Well, XML changes auto-modifying the UID sound awful, because it means you can't manually handle that change in serialized form and provide an implementation for de-serializing old serialized versions of a class; on the other hand, these are *generated* classes; if you wanted manual control, you shouldn't have generated in the first place. Downside: Unless the UID generation also includes some versioninformation from Castor, later versions of castor, which may generatecode differently, will not break that UID. Arguably, the castor build or version number should be included in UID generation hash. As for doing it the way Eclipse does: Eclipse compiles the class,runs the JVM to generate the serial version UID, and then inserts the serial version UID back into the Java source. This is doable if, forexample, you would like to include a dependency on the Eclipse java compiler with Castor - at which point, we can then take the source code, compile it, run java, and then using the AST tree that Eclipse's compiler provides, insert the correct node into the tree, resave the AST tree as java source on the disk, and continue.Whether or not the Castor developers wish to reconstruct their sourcegenerator on Eclipse AST trees is, of course, debateable. :) OTOH, it works just fine for the Tomcat folks. On 24 Jul 2005, at 21:24, Werner Guttmann wrote:Mind supplying us with a patch .. ;-) ? Given that Eclipse has some nice quick fixs in this area, this should not be too hard to achieve.------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
