[hibernate-dev] Voldemort maven module for Hibernate OGM

[Seiya Kawashima]

On Tue, Feb 28, 2012 at 1:47 PM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

>
> On 28 févr. 2012, at 19:41, Seiya Kawashima wrote:
>
> Thank you for your response.
>
> Unfortunately I'm not quite sure the reason that the Voldemort project
> doesn't push it to the maven repository. There are questions and
> discussions about the usage of the repository on the Internet, but it seems
> to me that there is no clear answer for the reason. Or I just have not
> noticed the existence.
>
> I have several questions about hibernate ogm core. These parts are that
> particularly I would like you to take a look at. The implementations might
> be awkward or incorrect.
>
>    1. To implement datastore providers for hibernate ogm, there are two
>    code styles. One is from MapBasedDatastoreProvider and the other is from
>    Infinispan and EhCache datastore providers. When we add other datastore
>    providers, which style should  we follow ? I've been referencing
>    MapBasedDatastoreProvider from the beginning of my experiment on Hibernate
>    OGM, the implementation followed  MapBasedDatastoreProvider.
>
>
> By style you mean architectural approach or code style (tab vs space)? If
> the former, then the MapBasedDatastoreProvider is a toy useful for us to
> abstract Hibernate OGM engine from a specific provider. You should use
> Infinispan as your example. But remember that Infinispan is full
> transactional and which makes the dialect somewhat easier to implement.
>

Yes, I meant the architectural approach in MapBasedDatastoreProvider. I
should have mentioned about the relationship between MapBasedDialect and
MapBasedDatastoreProvider as well. Within MapBasedDatastoreProvider, all
the CRUD logic for entities and associations and setNextValue() method are
implemented and those methods are called from MapBasedDialect. As a result,
MapBasedDatastoreProvider mixes its task and MapBasedDialect's task.
However, InifispanDatastoreProvider implements its task by itself and those
CRUD logic for entities are moved to InfinispanDialect. I'll follow
Infinispan and change VoldemortDatastoreProvider and VoldemortDialect.


>
>
>    1. To implement VoldemortDatastoreProvider.setNextValue() method, Iwas confused a little bit. I originally referenced other datastore
>    and implemented it, but on VoldemortDialectTest.testIsThreadSafe()which tests concurrency on the method, my
>    original implementation <https://gist.github.com/1903794> ran poorly
>    because it required an exclusive lock and datastore access every time
>    the method is called. And then I modified the method and got the
>    current implementation in VoldemortDatastoreProvider. However, it doesn't
>    quite reduce the number of accesses to the underlying datastore as I
>    wanted, but allows concurrency. As a result, I put a flag to store the
>    next value on the datastore or not. I'm not quite sure if this is the
>    right implementation or not.
>
> Some NoSQL stores have very efficient next value operations and this
> method is for them. You should try and make as efficient as possible but
> make sure it's safe. Your flag does not look like safe but I have not had
> time to investigate yet.
> And don't worry too much about performance. Properly set, Hibernate OGM
> will only call this method every 50 or so id generation required as we use
> a hi/lo algorithm by default to generate sequential ids.
>

I see. I'll take a look at the implementation again and see what I can do
for the method. The flag is set in VoldemortDatastoreProvider.start()
method and is not set afterwards, so I assume that it's safe. But even
though it's safe, it's still a awkward flag and would like to do something
about it.


>
>
>    1. To implement GridDialect.getLockingStrategy() method, the returned
>    object whose type is LockingStratey represents locks on underlying datatore
>    according to the javadoc. How should we implement this method when the
>    underlying datastore doesn't explicitly expose locks as objects ? Looks
>    like that Infinispan exposes some lock objects, so they are instantiated
>    and returned from the method. Voldemort has the concept of optimistic lock
>    exposing a method called voldemort.client.StoreClient.applyUpdate<http://project-voldemort.com/javadoc/all/>and Redis also has the concept exposing a method called
>    watch<http://www.jarvana.com/jarvana/view/redis/clients/jedis/2.0.0/jedis-2.0.0-javadoc.jar%21/index.html>and the
>    description <http://redis.io/topics/transactions#cas> . I use Jedis
>    2.0.0 <https://github.com/xetorthio/jedis> as Redis client.
>
> Now that's clearly the hardest part to map and we will have to chat on IRC
> about that. Hibernate has the notion of optimistic locking with this
> definition: if somebody applies a change before a change I am applying,
> then I lose. To do that it uses version number comparison and update where
> style operations.
>
> Now applyUpdate seems to be slightly different in the sense that they try
> and reapply a set of operations until they are not stale. That looks closer
> to a transaction than the Hibernate optimistic locking. But I need to have
> a chat with you to understand how people use it.
>
> Watch seems more akeen to pessimistic locking which you have to implement
> as well in LockingStrategy. But again, we will need to have a discussion
> about how people use that. Pessimistic locking in Hibernate means that I am
> guaranteed that noone will be able to do anything on my entry until I
> release the lock (usually by committing the transaction.
>
> I appreciate your explanation.  I'll discuss on this matter with you to
implement GridDialect.getLockingStrategy() correctly for Voldemort and
other datastores as well.  Before that, I'll familiarize myself with
LockingStrategy a little bit more.


> Form this discussion it also seems that we might need to have datastores
> and dialect implement the Hibernate transaction object so that the
> datastore can properly demarcate when isolation starts and when it ends.
> But that's clearly not abstracted yet in Hibernate OGM.
>
>
> Emmanuel
>
>



-- 
Thank you
Seiya