Difference between revisions of "Talk:COSMOSPersistenceFrameworks"

Revision as of 13:59, 20 April 2007

The chart arranging persistence solutions could benefit from further hammering.

First, these technologies seem out of place:

• Web 2.0
• JSON
• XML

I'm not sure what technologies these terms reference:

• Simple
• Managed Objects

Second, perhaps a 2nd dimension is needed -- much of the hibernate vs. ibatis discussions center around this issue: whether the application is database- or object- centric.

When the database is a shared resource (there are legacy applications that simultaneously access the database directly) the applications are more often than not database-centric. This database sharing introduces lots of complexity and limits. If there is caching done in the applications, it has to be write-through. Code has to manage dirty reads or read-through behavior. EJB2 addressed all of these requirements and is famous for bloat and sloth. Even if none of the applications do caching, instead relying on the database for caching, the applications need to expect deadlocks and timeouts caused by the behavior of their peers.

When the database is not shared (all accesses are done through a single application server), the applications can still be database-centric. Forces here might be a separation of powers between the Java developers and the database developers. Or, if the database's performance is a critical factor, the database schema may need to dictate the object design. (This is not to say that object-centric applications cannot perform.) Or, you might have a development team that is strong in SQL and less strong in Java.

Database-centric applications are generally developed in a database-platform-specific manner. They leverage vendor specific syntax for stored procedures, functions, extensions, in-memory temporary tables, indexing tricks, etc.

When the database is not shared, and is managed by a single application server, there is an opportunity for object-centrism to prevail. Object-centric applications make use of object-relational mechanisms for persistence (or they use the few remaining object databases for persistence). Object centric applications can perform well when they can leverage caching to achieve throughput, safely managing cache coherency. Add the need for distributed caching in order to achieve throughput, and you can end up with onerous complexity required for distributed cache coherence.

Anyway, the question here is: Is Eclipse COSMOS a database- or object-centric application.

Generally in the iBatis vs. hibernate debate, the iBatis solution works best with database centric applications, and hibernate works best with object centric applications.

Here's an interesting comparison of requirements and implementations from BEA. http://edocs.bea.com/kodo/docs40/full/html/jdo_overview_why.html The page includes this sentence: "JPA does not, however, support non-relational databases."