openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabio Martelli <>
Subject Re: Experimenting with MS SQL Azure federations
Date Fri, 01 Jun 2012 13:03:17 GMT
Hi Pinaki,
first of all thank you for your prompt reply and for references on OpenJPA Slice.
About what you say, please find my comments in-line.

Il giorno 30/mag/2012, alle ore 21.41, Pinaki Poddar ha scritto:

> Hi,
>  I liked your concise description of Slice -- a more verbose description is
> available at [1].
> Slice is designed to handle federation at JPA/application layer and via
> Slice it is possible to support a multi-tenant environment using a set of
> databases that are *not* federated by themselves. In fact, Slice can work
> with the databases that are heterogeneous as well. 

Right! ... and if I well understood, by specifying a distribution policy I can say to OpenJPA
where read&write specific data ...

> For Azure or other federated databases, the relevance of Slice is diminished
> as sharding concerns are handled by database server itself. From a JPA
> application standpoint, it will see a federated database as a "single"
> database. 

Sure, from a certain point of view I can agree.
Azure gives me the possibility to design and configure my federated SQL Azure database but
data distribution must be handled at the application layer.

In fact, by using OpenJPA as is my application won't be able to see and manage all the federations
but only the federation root database.
In this case I have no way to execute a statement on a particular federation but just on the
Further, things become more complicated when we consider that, usually, each federation is
composed of several members.

This is the reason why, from my point of view, in order to have a OpenJPA based application
with a federated SQL Azure db as a back-end we have to focus on:
1. how to distribute data among federations
2. how to distribute data among federation members

> So effectively, I see Slice and federated database as an either-or option,
> depending upon the design decision of which layer (database or JPA) is
> better suited to handle sharding. However, Slice does provide some extra
> features such as @Replicated types for master or reference data or query
> targeting. 
> I would like to know from your experience with federated databases, how
> these features are supported by Azure.

I think that slices can help to specify a data distribution policy against federations.

I start from the following considerations:
1. federations are not so subject to changes; from my point of view, federations are design
1. unfortunately, federation members seems to be more dynamic (someone could choose to split
members at runtime because a certain table is grown too much)

So, my idea is to consider a federation as a single database: in order to integrate the whole
federated db we can use more slices, one for each federation.
Data distribution policy against federations will be configurable thanks to Slice features.
Data distribution policy against federation members will be managed at runtime reading from
SQL Azures's sys tables member distribution for each federation.

I do think that by considering each federation as a single DB we can profit from all the features
of Slice. 

Please, let me know what you think.

Best regards,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message