Pinaki,
I like the idea.  I used to be involved with the ObjectGrid project here at
IBM and we used a similar technique for partitioning our in-memory cache.  I
have a few questions about Slice, but for the most part, I am in favor of
including it in the OpenJPA deliverable.

   - Basic question.  Is this support meant for databases that do not
   support partitions directly?  My experience has been that if a database
   supports partitioning directly, then the interaction with the database
   doesn't change at all.  That is, the application (or openjpa runtime in this
   case) does not have to change to take advantage of the partitioning.  It's
   transparent.  But, your documentation seems to indicate required slice
   configuration and callbacks.  I'm just trying to understand how you see this
   support fitting into the partitioned database landscape.
   - The DistributionPolicy interface seems a bit limiting.  The
   application code is now very tightly linked with the configuration.  The
   slice names in the configuration can not change without a corresponding
   change in the DistributionPolicy callback.  I would prefer something more
   general.  Maybe the callback could return an opaque Object based on whatever
   (key?) that could then be used by our runtime to determine the proper
   slice?  With ObjectGrid, we did this via a PartitionableKey interface that
   the primary key would have to implement.  We would then callback on the
   getPartition() method to get the Object value which we would then use to
   determine the partition.  This could be a String value, if so desired.  But,
   it also allowed other Object types as well.
   - When you mention possible "parallel execution", are you assuming the
   use of the openjpa "multithreaded" property for the EntityManagers?  Or,
   would this parallel execution utilize separate EntityManagers?
   - On first read, this support looks to be very cool for top-down
   development.  Depending on your response to the first bullet, I find it
   harder to understand how a customer might already have a poor-man's version
   of partitioning and work upwards.  Just thinking outloud...

Like I said up-front, I like the basic idea of Slice.  I think we probably
need a bit more discussion on how this fits into the overall database
landscape and architecture, but eventually I would like to see this become
part of OpenJPA.  Thanks and nice work.

Kevin


On Jan 30, 2008 5:44 PM, Pinaki Poddar <[EMAIL PROTECTED]> wrote:

> Hi,
>  I would like to add an extension of OpenJPA that allows an application
> to transact against a set of distributed, possibly hetereogenous,
> horizontally-partitioned databases [2]. The project is named as Slice
> and is similar in scope to Hibernate Shards.
>  The development codebase so far been maintained in Apache Lab
> repository and given its current state I propose to add the codebase to
> a new openajpa-slice module.
>
>  I request you to review current state of its implementaion [1] and
> express your opinion/views on feasibility of my proposal.
>
>  Regards --
>
> Pinaki
>
> [1] Slice website:
> http://people.apache.org/~ppoddar/slice/site/index.html<http://people.apache.org/%7Eppoddar/slice/site/index.html>
> [2] dev2dev blog:
> http://dev2dev.bea.com/blog/pinaki.poddar/archive/2008/01/slice_openjpa_
> f_1.html
>
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and
> have received this message in error, please immediately return this by email
> and then delete it.
>

Reply via email to