openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <>
Subject Re: Experimenting with MS SQL Azure federations
Date Tue, 14 Aug 2012 10:36:08 GMT
On 14/08/2012 12.30, Mark Struberg wrote:
> All this stuff is pluggable and only uses the SPI, right?

Correct: you can take a look at the current feasibility study 
implementation [1] source code for this; anyway, we plan to keep this 
also for the upcoming full implementation.

I can think that - maybe - we'd need to introduce some more SPI 
somewhere in order to have a cleaner integration, but I cannot be 100% 
sure at the moment.

> Are there comparable features needed for other NoSQL/bigdata storages as well?

Hum, I have very poor knowledge about such topics...


> ----- Original Message -----
>> From: Francesco Chicchiriccò <>
>> To:
>> Cc:
>> Sent: Monday, August 13, 2012 4:18 PM
>> Subject: Re: Experimenting with MS SQL Azure federations
>> Hi all,
>> anyone interested in this topic?
>> After the initial feasibility study, our customer is now about to
>> commission the whole implementation.
>> We can release this under AL 2.0 and put it somewhere (apache-extras,
>> github), but if possible we would like to involve the OpenJPA community
>> in this, possibly contributing to mainstream OpenJPA code & doc.
>> WDYT?
>> On 30/05/2012 12.09, Francesco Chicchiriccò wrote:
>>>   Hi all,
>>>   one of my company (Tirasa) customers asked Fabio Martelli (in CC) and me
>>>   to start exploring the integration between OpenJPA and MS SQL Azure
>>>   federations.
>>>   After some work we came out with [1], a sample webapp with persistence
>>>   layer (managed by OpenJPA) on MS SQL Azure; moreover, this sample code
>>>   makes profit of federations [2], a way to perform table partition, close
>>>   to the "sharding" concept.
>>>   SQL Azure federations were initially considered as mappable to OpenJPA
>>>   slices: in fact, both refers to 'sharding', however with slight
>>>   different meaning.
>>>   OpenJPA slices provide their own mechanism to handle at application
>>>   level distributed queries, data distribution and data replication1; SQL
>>>   Azure federations, instead, push such aspects to database configuration
>>>   level and empowers the ability to change some of these at runtime.
>>>   For example, with OpenJPA slices can be configured so that records from
>>>   table Person with field id value < 500 will be handled by slice1, while
>>>   the rest will be handled by slice2, where slice1 and slice2 are two
>>>   separated databases. This breaks the SQL Azure federations model,
>>>   because the Person table of this example can be dynamically split at
>>>   runtime, thus generating one or more federation members at persistence
>>>   level.
>>>   This implies that the actual federation member for a given record
>>>     * cannot be determined by configuration -- as OpenJPA slices require,
>>>   but only at runtime;
>>>     * cannot be chosen at application level but is enforced by persistence
>>>   level.
>>>   At the end, SQL Azure federations provide an additional scalability
>>>   layer and can then be seen as complementary to OpenJPA slices, rather
>>>   then opposite.
>>>   If anyone is interested, we also wrote a simple wiki page [3] about how
>>>   to get our demo code up an running.
>>>   Any feedback is welcome.
>>>   Our customer is currently evaluating whether to extend this feasibility
>>>   study with a complete implementation and would also like us to
>>>   contribute such code back to OpenJPA community.
>>>   Fabio Martelli and I are already ASF committers and PPMC members at
>>>   Apache Syncope [4], IdM solution with persistence based on OpenJPA.
>>>   WDYT?
>>>   Regards.
>>>   [1]
>>>   [2]
>>>   [3]
>>>   [4]

Francesco Chicchiriccò

ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member

View raw message