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...
Regards.
----- Original Message -----
From: Francesco Chicchiriccò <[email protected]>
To: [email protected]
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/
