Slice: OpenJPA for distributed persistence

[pinaki...@gmail.com]

Hello,
Inspired by Hibernate Shards, I have developed Slice -- a
distributed persistence for JPA based on OpenJPA.

http://people.apache.org/~ppoddar/slice/site/index.html

Your comments and feedback are most welcome.

Regards --

[Emmanuel Bernard]

nice,
I saw one of your reply on TSS:
"ii) Slice is based on OpenJPA (http://openjpa.apache.org) as JPA
runtime. Given my association with OpenJPA (am a committer), I could
provide some user-friendly features. For example, data distribution
policy is only to be specified for newly persistent object graph
roots. The instances loaded via query or find() are tagged with the
original database automatically.

iii) Slice also provides two-phase commit across the slices provided
the underlying database resources are XA-complaint. "

you sort of imply Slice does that while Shards does not. Actually
Shards does ii and iii as well (for iii, it's more than Shards does
not care at all and lets JTA do it's job).

Other question, do you deal with group by, having and aggregation?

[pinaki...@gmail.com]

> you sort of imply Slice does that while Shards does not.

I do not. If my words carry that implication, my sincere apologies. (I
will post this clarification in Serverside as well)

As I said, I am inspired by Hibernate Shards to work on Slice.

> for iii, it's more than Shards does not care at all and lets JTA do it's job

What happens when no JTA transaction manager in the environment? e.g.
in JPA parlance, a persistence unit with transaction-
type=RESOURCE_LOCAL

> Other question, do you deal with group by, having and aggregation?

Not yet. Slice is at version 0.4.0. Unique result aggregation can be
accomplished with the current approach of merging results from
different sources, but sorting /group by / having all are in
conceptually difficult domain right now. How about Shards on this
account?

On Jan 9, 5:54 pm, Emmanuel Bernard <o...@emmanuelbernard.com> wrote:
> nice,
> I saw one of your reply on TSS:
> "ii) Slice is based on OpenJPA (http://openjpa.apache.org) as JPA
> runtime. Given my association with OpenJPA (am a committer), I could
> provide some user-friendly features. For example, data distribution
> policy is only to be specified for newly persistent object graph
> roots. The instances loaded via query or find() are tagged with the
> original database automatically.
>
> iii) Slice also provides two-phase commit across the slices provided
> the underlying database resources are XA-complaint. "
>
> you sort of imply Slice does that while Shards does not. Actually
> Shards does ii and iii as well (for iii, it's more than Shards does
> not care at all and lets JTA do it's job).
>
> Other question, do you deal with group by, having and aggregation?
>

[Emmanuel Bernard]

Resending, wrong email

On Jan 10, 2008, at 10:02, Emmanuel Bernard wrote:

>
> On Jan 10, 2008, at 01:14, pinaki...@gmail.com wrote:
>>
>>> for iii, it's more than Shards does not care at all and lets JTA
>>> do it's job
>> What happens when no JTA transaction manager in the environment? e.g.
>> in JPA parlance, a persistence unit with transaction-
>> type=RESOURCE_LOCAL
>

> It's simply isolated transactions committed one after the other.

>
>>
>>> Other question, do you deal with group by, having and aggregation?
>> Not yet. Slice is at version 0.4.0. Unique result aggregation can be
>> accomplished with the current approach of merging results from
>> different sources, but sorting /group by / having all are in
>> conceptually difficult domain right now. How about Shards on this
>> account?
>

> For Java Persistence queries, we have the same issue, it requires
> to have some inputs from the query parser. But the Criteria API
> handles that.