[infinispan-dev] OGM, Hot Rod and Grouping API
mudokonman at gmail.com
Fri Jun 6 09:04:17 EDT 2014
On Fri, Jun 6, 2014 at 8:51 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> We expect the same semantic as a RDBMS in READ_COMMITTED. getGroup() would be equivalent to a select * from ASSOC_TABLE where owner_id = 2. Phantom reads would be acceptable.
Yeah we can't currently stop any phantom reads.
> Does that answer your question? Because I’m not sure what you mean by the key being attached to the Tx.
The difference is say you have a tx1 on thread 1 then on the same
thread you ask for the group, if it is in the transaction controls
whether or not that pending update is seen.
// Note key1 is in group 1
Set<K> keys = cache.getGroup("group1");
// The keys would contain key1 if taking part of transaction.
> On 06 Jun 2014, at 14:38, Pedro Ruivo <pedro at infinispan.org> wrote:
>> Hi Davide,
>> what kind of transactional semantics are expected? when you invoke
>> getGroup(), do you expect the keys to be attached to the transaction (in
>> the read-set). same question for removeGroup()
But the reason I brought up transactions is I was concerned about
removeGroup being used in a non tx way since it would be very prone to
lock timeouts since you could be calling it from the same thread that
has a transaction that holds a lock on one of those keys.
>> On 05/28/2014 11:52 AM, Davide D'Alto wrote:
>>> Hi all,
>>> some time ago we talked on the mailing list about the integration
>>> between Hibernate OGM and Hot Rod.
>>> To achieve this we would need to include the grouping API in the Hot Rod
>>> protocol and to add a couple of methods in the grouping API:
>>> - to get the keys in a group
>>> - to remove the keys in a group
>>> Mircea created an experimental stub where the method " <G, KG> Set<KG>
>>> getGroupKeys(G group) " is added to the Cache interface.
>>> I've rebased the branch to the latest changes (I might have introduce
>>> some errors): https://github.com/DavideD/infinispan/compare/ISPN-3981
>>> I should have implemented the methods but I haven't had the time to work
>>> on these features.
>>> There are also two issues to keep track of this:
>>> As far as I know, the API for Infinispan 7 is going to be freezed soon,
>>> I was wondering if this changes have been taken into account and,
>>> if not, is it possible to include them?
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
More information about the infinispan-dev