Skip to main content
Jump to: navigation, search


Revision as of 14:23, 18 November 2010 by (Talk | contribs) (Comments added to the bug: new section)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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. 13:23, 1 November 2010 (UTC)

The document is missing some details on how the user will configure the datasource/connection pool information. Given the persistence.xml file has only one element for a datasource how will users using JPA configure the other datasources and provide identifiers for them.

Gordon Yorke 14:24, 17 November 2010 (UTC)
Updated the doc 16:45, 17 November 2010 (UTC)

What does the PartitionPolicy interface look like and what information will be available to users implementing custom PartitionPolicies?

Gordon Yorke 14:27, 17 November 2010 (UTC)
Updated the doc, the API is,
public List<Accessor> getConnectionsForQuery(AbstractSession session, DatabaseQuery query, AbstractRecord arguments) 16:45, 17 November 2010 (UTC)

Comments added to the bug


Back to the top