-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Matthew Baird <[EMAIL PROTECTED]> > Date: Wed, 24 Apr 2002 08:48:09 -0700 > > Something that really held up development was; Everytime a change was > requested/proposed, someone would talk about the big refactoring and > architecture change that was coming (Someone else mentioned this point > already). I don't think this refactoring/arch change is coming for a LONG > time, unless Thomas and the exolab declassify the design documents/plans for > the change and donate them to the community so someone else can make the > change. > > I see this as a survival move for Castor, as there are starting to be other > more actively developed projects sneaking up on them (OJB Anyone?) > > so..... FREE THE INFORMATION! Let us peek at the proposed plans for JDO and > let us pick it up and continue!
Heh... "You say you wanna revoultion... yeah yeah you know... we don't wanna change the world..." Sorry... didn't mean to 'burst' out into song... couldn't help myself. (and I especially apologize if I got the lyrics wrong) There are really two issues here that people have hit on. The first is that the future direction of Castor is somewhat unknown. The second is that enhancements are slow in coming. Of course, things like better documentation may help the flood of requests on the mailing list, but really those are almost secondary. The community that has built up around Castor is really the focus point, and how new users get most of their help. I cannot really address these two main issues myself; though I'm a committer, I don't work for Exolab and can't speak on the direction for Castor. And as far as enhancements go, I tend to focus on getting Castor JDO with PostgreSQL being a good replacement for TopLink/Oracle. This makes my personal focus fairly narrow. However, one of the issues that I directly am trying to fix is being able to manually remove objects from the cache. As Thomas mentioned, this is more tricky than it sounds since there are deadlock scenarios that can occur during this. I've even seen deadlocks occur in my current production usage of Castor with lazy collections in certain cases... and rare timing issues exist as well even without lazy collections. The need for the refactoring is obvious, considering these issues I mentioned. What to refactor is tricky, and fairly complex. (See the code base if you don't believe me. :-) However, the real problem is time; Exolab/intalio started this project, and gets to decide direction. But regardless of the long term direction, there are things we can do now to, in a sense, assist with the 'big refactoring'. For me, getting the cache more 'open' is a must. (Especially if we want a distributed cache) But to do this requires us to refactor just enough so that we understand and dealt with these timing issues. So, let me make a request to the Castor JDO community... for those who have a good understanding of threading issues and have some understanding of the internals for Castor source, examing the caching system. Look at the past posts made by Thomas and others about deadlock problems in the current system. And lets review and discuss where these deadlocks may occur and start working on test cases that show them. To me, this is the best way to go forward. (And for those who can't understand the source code, or haven't solved deadlock conditions, you can help by simply testing/using Castor. The more its used, to more we'd be likely to find the problems.) - -- Virtually, Ned Wolpert <[EMAIL PROTECTED]> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key at http://www.keyserver.net iD8DBQE8xuV5iysnOdCML0URAlhUAJ9QxA+nMv1eZzaL2wMDoJoaM5uTcACdGoha STsOCmT321M2Ye9lGqotCiU= =+uj8 -----END PGP SIGNATURE----- ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
