openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
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?


LieGrue,
strub


----- Original Message -----
> From: Francesco Chicchiriccò <ilgrosso@apache.org>
> To: dev@openjpa.apache.org
> 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] https://github.com/Tirasa/protojpasqlazure/
>>  [2] http://msdn.microsoft.com/en-us/library/windowsazure/hh597452.aspx
>>  [3] https://github.com/Tirasa/protojpasqlazure/wiki/Setup
>>  [4] http://incubator.apache.org/syncope/
> 
> -- 
> Francesco Chicchiriccò
> 
> ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
> 

Mime
View raw message