openjpa-dev mailing list archives

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

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


----- 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.
> 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