Gregory, >> Well, if that's the case .. ;-), what would you think about helping us >> with testing new code, whether it's a feature such as support for >> lazy-loading 1:1 relations or support for the transient attribute at the <sql> >> level. >> Right now, I've got a patch posted for the transient support, and I'd >> be very interested to get some hands-on comments. >> >> Interested ? >> > >We're always willing to test; hell, we're currently running off of last >week's CVS on staging, and my dev system is using yesterday's CVS >build. :) Well, the problem with the transient stuff is that I'd rather not commit this without some people testing this by applying a patch themselves. Iow, if you'd be willing to get the sources from CVS, apply a patch and run things your way, you'd be more than welcome. If that's an option for you, please have a look at bug 1210, and let me know what you needed from me.
>At the moment, we've got caches disabled on the system, for most of our >objects, due to the performance problems we've had with the >castor-level cache. Interesting. Can you please elaborate a bit more as to where the performance problems are (in general), what cache types you've been using, etc. I'd be eager to learn as to what could be done to improve code. >.. gets built to build a cache implementation into our replacement >implementation for the memcached distributed cache infrastructure, for >example, to ensure that objects loaded out of JDO on any of our servers >gets stuck in distcache and is available for others to use without >needing to hit the database... > >If you're taking wishlists... > >1) lazy-load of 1:1 relationships. I am working on this as I write .. ;-). Have a look at http://bugzilla.exolab.org/show_bug.cgi?id=1676, but let me first add a couple of more comments. >2) lazy-load of blobs, clobs, and other large object types. Not really on my agenda, to be honest, but I could change my mind here ... > >and longer term... >3) out-of-transaction lazy load capabilities, where the getter on the >object has code inserted on class-load to insert the necessary JDO call >based on marking the field/object as lazy. :) Well, I can easily think of a solution based on option 1), as I will be using java.lang.reflect.Proxy for the implementation, and I cannot think of any problems with this approach to achieve 'out-of-transaction' lazy loading. > >Current things worthy of note: > - Most of the OQL is gone from the system now; our use of caching has >made it pretty much a prerequisite that we cache id lists for SQL >queries on finders and only use db.load() on calls. While I'd love >that to change, the OQL engine just wasn't far enough along to be able >to represent our queries. Afaik, Bruce is still thinking about replacing the whole OQL engine with a more advanced solution. But I have to leave it up to him to present his own thoughts on thi subject. > - We're currently not doing much in the way of DB writes at this >point; the new user management system will use create/update, but >everything else is currently read-only data. That will change, but I'm >not sure when. So I won't be of much help in finding those kinds of >problems. > >So we're pretty emphatic about the need on our side for good read >performance, but limited in our ability to test the other parts of the >code. The better that OQL gets at supporting syntax, and the better it >gets at being able to cache the results of those queries while storing >individual objects loaded from DB in the same manner as db.load() does, >the more we can consider switching that code back out of SQL into OQL, >which is something we're definitely interested in doing. > >The new memcached client, and any Castor cache driver that comes out of >that work, will get LGPL'd at some point. You do have an awareness that the performance caches are now pluggable, don't you ? Iow, wit the current code in the CVS repository, you now have the means to provide your own cache implementation(s) and register them with Castor .. and use them. I still do have plans to build a performance cache implementation that uses e.g. JCS or JavaGroups as the underlying mechanism for a distributed cache instance. There is a bug out there (whose number I simply cannot remember right now .. :-( ) serving as a reminder, but that's how far I managed to get right now. Too many things going on at the same time. I'll add yet another one to remind me that I'll need to update the docs as well to highlight this new feature. On top of this, there is a new implementation of TimeLimited out there with improved performance, but we have not checked it it yet as it requires JDK 1.3. Werner >There's a lot of other stuff >- a SOAP/HTTP framework for data retrieval, for example - is currently >too closely tied to the rest of the architecture, but as that changes, >I do hope to LGPL more of it and release it, if for no other reason >than as example code for Castor. ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
