7:01 a.m.
Hi,
I wrote sample implementations for Voldemort,Redis and Riak on Hibernate OGM a couple of
weeks ago. Based on them, I created a Voldemort maven module and put it on my github
repository at https://github.com/seiyak/hibernate-ogm. The project was forked from the
original one and the modifications were applied on it following Emmanuel's advice on
the previous mailing list. I put README.md in hibernate-ogm-voldemort directory, so please
read it before typing 'mvn clean install'. Voldemort needs to be installed
manually into the local maven repository as of the version 0.90.1.
According to the supplied tests, it looks fine. However, I need advice and suggestions to
make it better,cleaner and right if there is something incorrect. I'll ask several
questions that I got during the programming later.
Please let me know what you think of the code. If it's worth of a part of Hibernate
OGM, I would like to contribute it.
Thank you
Seiya
6:06 p.m.
Hi Seiya,
Many thanks for this work and sorry for the delay in answering. I / we will definitively
have a look. We have strong deadlines for mid-week on Hibernate Search, but I'll have
more time after that.
Do you know why the Voldemort project does not push it to a maven repository. Is that
because they are busy doing something else or is that because they do not want it for some
other reasons? I am thinking of using the JBoss Maven repo and push it there.
Emmanuel
On 24 févr. 2012, at 23:01, <skawashima(a)uchicago.edu>
<skawashima(a)uchicago.edu> wrote:
Hi,
I wrote sample implementations for Voldemort,Redis and Riak on Hibernate OGM a couple of
weeks ago. Based on them, I created a Voldemort maven module and put it on my github
repository at https://github.com/seiyak/hibernate-ogm. The project was forked from the
original one and the modifications were applied on it following Emmanuel's advice on
the previous mailing list. I put README.md in hibernate-ogm-voldemort directory, so please
read it before typing 'mvn clean install'. Voldemort needs to be installed
manually into the local maven repository as of the version 0.90.1.
According to the supplied tests, it looks fine. However, I need advice and suggestions to
make it better,cleaner and right if there is something incorrect. I'll ask several
questions that I got during the programming later.
Please let me know what you think of the code. If it's worth of a part of Hibernate
OGM, I would like to contribute it.
Thank you
Seiya
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:10 p.m.
Just for my personal record, the process to upload a 3rd party dependency to JBoss repos
is here https://community.jboss.org/wiki/UploadingAThirdpartyArtifact
On 28 févr. 2012, at 10:06, Emmanuel Bernard wrote:
Hi Seiya,
Many thanks for this work and sorry for the delay in answering. I / we will definitively
have a look. We have strong deadlines for mid-week on Hibernate Search, but I'll have
more time after that.
Do you know why the Voldemort project does not push it to a maven repository. Is that
because they are busy doing something else or is that because they do not want it for some
other reasons? I am thinking of using the JBoss Maven repo and push it there.
Emmanuel
On 24 févr. 2012, at 23:01, <skawashima(a)uchicago.edu>
<skawashima(a)uchicago.edu> wrote:
> Hi,
>
> I wrote sample implementations for Voldemort,Redis and Riak on Hibernate OGM a couple
of weeks ago. Based on them, I created a Voldemort maven module and put it on my github
repository at https://github.com/seiyak/hibernate-ogm. The project was forked from the
original one and the modifications were applied on it following Emmanuel's advice on
the previous mailing list. I put README.md in hibernate-ogm-voldemort directory, so please
read it before typing 'mvn clean install'. Voldemort needs to be installed
manually into the local maven repository as of the version 0.90.1.
>
> According to the supplied tests, it looks fine. However, I need advice and
suggestions to make it better,cleaner and right if there is something incorrect. I'll
ask several questions that I got during the programming later.
>
> Please let me know what you think of the code. If it's worth of a part of
Hibernate OGM, I would like to contribute it.
>
> Thank you
> Seiya
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:41 a.m.
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.
2. To implement VoldemortDatastoreProvider.setNextValue() method, I was
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
valueon the datastore or not. I'm not quite sure if this is the
rightimplementation or not.
3. 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/...
Redis also has the concept exposing a method called
watch<http://www.jarvana.com/jarvana/view/redis/clients/jedis/2.0.0/je...
the
description <http://redis.io/topics/transactions#cas> . I use Jedis
2.0.0<https://github.com/xetorthio/jedis>as Redis client.
Thank you once again.
Seiya
On Tue, Feb 28, 2012 at 3:10 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
Just for my personal record, the process to upload a 3rd party
dependency
to JBoss repos is here
https://community.jboss.org/wiki/UploadingAThirdpartyArtifact
On 28 févr. 2012, at 10:06, Emmanuel Bernard wrote:
> Hi Seiya,
>
> Many thanks for this work and sorry for the delay in answering. I / we
will definitively have a look. We have strong deadlines for mid-week on
Hibernate Search, but I'll have more time after that.
>
> Do you know why the Voldemort project does not push it to a maven
repository. Is that because they are busy doing something else or is that
because they do not want it for some other reasons? I am thinking of using
the JBoss Maven repo and push it there.
>
> Emmanuel
>
> On 24 févr. 2012, at 23:01, <skawashima(a)uchicago.edu> <
skawashima(a)uchicago.edu> wrote:
>
>> Hi,
>>
>> I wrote sample implementations for Voldemort,Redis and Riak on
Hibernate OGM a couple of weeks ago. Based on them, I created a Voldemort
maven module and put it on my github repository at
https://github.com/seiyak/hibernate-ogm. The project was forked from the
original one and the modifications were applied on it following Emmanuel's
advice on the previous mailing list. I put README.md in
hibernate-ogm-voldemort directory, so please read it before typing 'mvn
clean install'. Voldemort needs to be installed manually into the local
maven repository as of the version 0.90.1.
>>
>> According to the supplied tests, it looks fine. However, I need advice
and suggestions to make it better,cleaner and right if there is something
incorrect. I'll ask several questions that I got during the programming
later.
>>
>> Please let me know what you think of the code. If it's worth of a part
of Hibernate OGM, I would like to contribute it.
>>
>> Thank you
>> Seiya
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Thank you
Seiya
4:47 a.m.
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.
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.
To implement VoldemortDatastoreProvider.setNextValue() method, I was
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 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.
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 and
Redis also has the concept exposing a method called watch and the description . I use
Jedis 2.0.0 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.
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
2:39 a.m.
On Tue, Feb 28, 2012 at 1:47 PM, Emmanuel Bernard <emmanuel(a)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/...
Redis also has the concept exposing a method called
watch<http://www.jarvana.com/jarvana/view/redis/clients/jedis/2.0.0/je...
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
4451
days inactive
4456
days old
5 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Seiya Kawashima -
skawashima＠uchicago.edu