This one time, at band camp, tek1 said: t>At 10:36 03/06/10 -0700, you wrote: t> t>>1. This workaround worked. Ideally we would like to turn castor caching t>>off - we use JCS for caching - it gives us better control over the caching. But t>> t>>seems like it is impossible to turn caching off for long transactions. t> t>Yes, I believe that long transactions can't work without Castor's internal t>caching. Regarding JCS, are you using it for clustering? One of the t>features that is being planned for the next major version of Castor is a t>plugable (distributed) cache architecture that supports clustering. Would t>you be interested in sharing your insights about how we might be able to t>use JCS with Castor, and perhaps like to help out?
The only problem I see with JCS is that it is not JCache compliant and I have no idea whether it will be once the JCache spec is released. BTW, I'm told that the JCache spec has changed wildly from the PDF that's posted on the JCache JSR website. Regarding the caching refactoring, I'm going to make use of JavaGroups for the distributed caching and for the local, stand alone caching, I'm probably going to use the TreeCache that Bela created to work with persistence. t>>2. Another workaround that also works and which I discovered from another t>>post is to clone the object before updating - though I can't understand t>>why that solution works. This seems odd to me as well. I'm willing to hazard a guess that there's more context surrounding the cloning solution that is mentioned here. t>Seems like an application would take a severe memory hit if it has to t>clone every persistence object before updating. Not sure of the Castor t>internals, but that might result in multiple copies of similar objects in t>the cache. t> t>Does anyone know if there are design diagrams for Castor? Trying to t>interpret everything from the code alone is quite a task. The traditional response is that we don't maintain these because the APIs are always changing. Why then do we provide Javadocs? The short answer here, IMO, is that the generation of the UML, 1) requires human intervention, and 2) cannot be accomplished easily by using Ant. Generation of UML is left as an exercise for the user. Check out Poseidon for UML (http://www.gentleware.com/) for a free modeling tool that will generate UML from preexisting objects. Of course, there's all the commercial solutions as well. t>>3. db.load() won't work for us - we have too many updates and loading the t>>object each time would be too costly. t> t>I was under the impression that db.load() attempts to access the cache t>before accessing the db...? Yes, it does. Currently this is one thing that load() does that OQL does not. t>>4. It would be great to have one central place which gives the final word t>>on known bugs and workaround(s) for every version. I have always been able t>>to find the solution/workaround on the mailing list but it also very t>>frequently has suggestions and it takes a long while to try out all the t>>suggestions and arrive at the perfect solution/workaround...maybe there is t>>already such a place and I haven't discovered it. Unfortunately there are at lease a couple of reasons for this: - The Castor Project is hosted by Intalio and we have no direct access and very little influence about what can be done with those servers. - The Castor Project is maintained by people who work on it in there spare time. All committers currently have a day job other than the Castor Project. I've thought about creating and linking to a Castor Doc project on SourceForge that maintains a searchable knowledge base, a Wiki, etc. But, like all other things, that takes time. - There are really only four active committers on the Castor Project. We're constantly in search of more people who are willing and able to contribute time and code to the project. Many thanks to Lance Lavandowska for starting the Castor Wiki. IMO, this is a very necessary tool because of it's organic nature. Bruce -- perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
