Re: [castor-dev] Strategy Proposal (repost - was: Castor JDO Status)

[Thomas Yip]

To be very frank. I don’t see immediately need of doing those things, even for the points I agree.   I think getting what is in the commonly request list is enough for me to worry. If those are not done, I don’t really see people are going to keep using Castor JDO in the future anyway. So, I don’t see value on discussing something too far away. And, I am pretty sure that more “ideas” like that isn’t what it takes for success of Castor JDO, but actually get things done.   So, I will withdraw from those discussion from now on.         Thomas             -----Original Message----- >From: Ilia Iourovitski [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, May 01, 2002 2:10 AM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Strategy Proposal (repost - was: Castor JDO Status) > >The functionality of "MBean Server" is to: >1. Load configuration >2. Load components with dependencies. >3. Initialize >4.Start/stop/monitor. >Currently this functionality located in jdo.JDO, jdo.engine.DatabaseRegistry, jdo.engine.JDOMappingLoader. >The main component is SPI provider. It implements interfaces under persist.spi. Currently there is only one >SQL engine with DAX in refactoring. >Additional pieces which can wrapped as component are: >1.Cache >2. Query model : SQL/OQL/SODA/XPath/java JDO query language/Programmable API for building query. >3. LockEngine with policies. It should be possible to set on LockEngine per jvm, per database connection, per transaction to provide ACID properties. Optimistic locks using timestamps, version, state changes or native database update detection goes here. >4. Transaction. (Pessimistic, optimistic). >As I've seen in AvalonDB and OJB it is became fashionable to implement insert/update/delete/query operations as actions. They can be wrapped as MBeans too. >Thanks >Ilia >  Bruce Snyder <[EMAIL PROTECTED]> wrote: >All, > >It seems to me that the next logical step is to discuss the current >API vs. what it should become. IMHO, David's proposal to construct >Castor using both JCA and JMX is superb. In order to get started >on this, we must first decide what portion(s) of the current API >should be considered the core of Castor JDO and what pieces of the >current API can be broken out into their own modules (e.g. conf, >drivers, oql, etc.). However, I think that the current API could >stand to be broken up (e.g. engine and persist really need to be >split up) into more logical packages. Thomas, Ilia and Ned have >already been discussing this a bit (caching, locking, etc.) but >only a small portion. Let's expand this discussion to include what >should be the Castor JDO core and what should be a module. My >thinking on this stems from the fact that the part of the core willbe an implementation of an MBean server architecture and the modules >can be implemented as MBeans and at least the drivers could be >implemented using JCA. > >Again, I may be fired up about nothing, but I certainly like David's >proposal. To me, this modular architecture is truly what has propelled >JBoss to the next level. > >Bruce >-- > >perl -e 'print unpack("u30","<0G)U8V4@4VYY9&5R"F9E<FEI+F-O;0``");' > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: >unsubscribe castor-dev > ><img/> >Do You Yahoo!? >Yahoo! Health - your guide to health and wellness >