Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Talk:EclipseLink/DesignDocs/328937

First, let me appreciate James for coming up with this excellent Project Idea. This will make eclipselink the ideal persistence solution for any application that needs to scale; Adding Replication to the list of supported features makes this project all the more useful for enterprises. Today, companies have to rely on several different tools one for persistence, one for caching, one for replication, one for scaling, etc. When this project is completed, eclipselink will become the one-stop solution for accessing databases for any java based applications.

Now there seems to be collision in the efforts needed for accomplishing the two concepts:

1) Database Partitioning (EclipseLink/DesignDocs/328937) and

2) JPA Support for Session Broker (EclipseLink/DesignDocs/328404).

Shouldn't they both be brought under one umbrella? Otherwise, the JPA Support API for session broker may need to be altered again to support the partitioning features. It would be better to to track the development of these two subsystems of eclipselink on the same wiki page.

Thank you for your comments. The two features are definitely related but they do fill two very different use cases. Partitioning is for accessing multiple homogeneous instances of the same database, or a database cluster. It provides scalability and fault tolerance.
Session broker provides an integrated view on multiple different heterogeneous databases. Its goal is to provide data integration, not scaling or fault tolerance. Session broker is targeted at applications that need to integrate a legacy database (or even a non-relational EIS system) with newer relational data. Session broker can also provide a view on a large organizations multiple different databases, and works well with organizations form from mergers and acquisitions that need to access multiple different heterogeneous databases. The session broker solution is more complex than database clustering as it must be able to access different data sources with different SQL dialects, or even non-relational systems.
We are building both features together and will ensure that they work with each other.
James.sutherland.oracle.com 13:23, 1 November 2010 (UTC)

Back to the top