ALL
I have around of two years of experience of production use of Castor and here is my random thoughts about it's status.
1.Castor/Intalio is not the first Open source project who run out money/resources and need active community to stay alive. The TCL/TK (or Python) community could be used as example. Both of them adopted mechanism of Enhancement Proposals, which consists from Abstract/Specification/Rationale/Reference Implementation. Just one look at PEPS or TIPs http://www.tcl.tk/cgi-bin/tct/tip/ gives understanding about directions of those communities.
2.Another projects (most notably in Jakarta land) has sandbox(scratch pad) directory in CVS where developers can put experimental code.
3.Features. Adding more and more features to the current code base will only creates more bugs and makes
Castor even more slow. The current code base should be cleanup from commented code and the classes which has major number of bugs refactored. The main line of Castor development should be changed from
adding more and more sweet features toward modularithation. Pluggable cache, datasource, query model (OQL, SQL, SODA). Currently Castor JDO build as one monolithic product.It is not possible to access lower level of Castor JDO for performance reason.
4. Performance: In my test Castor JDO around 2 times slower than jdbc when retrieving 1000 records from database using one class per table mapping. It getting worse in case of many threads. The Torque and OJB
have 10-20% difference with jdbc. This needs to be improved by pregenerating code, using BCEL for byte code insertion.
5. Directions: Typically database applications falls into three flavor with different requirements:
a: Using RDBMS to store application configuration. Typical case - Personalization system which keeps data about customers, products, prices, and so on. There is rich class hierarchy, data read on start of system, wrote on shutdown. Data rarely updated. Data must be cashed. This is probably was design goal for Castor.
b: Heavy transaction processing, like credit card processing. Small number of table/classes, simple binding, tons of threads. In current version Castor not well suited for it because it is trying to keep one object for particular id in jvm, which let to synchronization/deadlock in concurrent transactions. Especially when some transactions are reading and another writing data into database.
c: Reports. Many joins and needs to get big junks of data from database quickly. Data required sorting, grouping.
it is not feasible that Castor JDO can feed all of them at one time, so probably it should be position as framework which can be fine tuned for different needs. Like if I need to unload data from database for performance reasons it would be nice to Service Providers directly, bypassing locks, caches, etc.
Thanks
Ilia
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
