6:54 a.m.
Just getting a discussion going on this since a JIRA has now been created.
Basically, the way I see it is that we can check which keys in the cache
have already been used - but that's context specific (I'll probably need
a quick explanation to how the InvocationContexts work). The question
for the gurus of ISPN here is whether or not this is going to be an issue.
The plan of attack is as follows: -
1 - User does a put()
2 - Interceptor checks the set of keys used within the same context to
see if the same key has been used
3 - If it has an UPDATE is used.
4 - If not we do an ADD.
Reckon that sounds okay?
--
Navin Surtani
Intern Infinispan
7:29 a.m.
Hi,
It's probably a question everyone knows the answer, but I'll ask anyway.
Make a UPDATE work on index, is not the same thing to do steps 2, 3 and 4? Or
UPDATE is computationally more expensive? Or there is another reason to
avoid the UPDATE?
Israel
On Wed, Jul 21, 2010 at 8:54 AM, Navin Surtani <nsurtani(a)redhat.com> wrote:
Just getting a discussion going on this since a JIRA has now been
created.
Basically, the way I see it is that we can check which keys in the cache
have already been used - but that's context specific (I'll probably need
a quick explanation to how the InvocationContexts work). The question
for the gurus of ISPN here is whether or not this is going to be an issue.
The plan of attack is as follows: -
1 - User does a put()
2 - Interceptor checks the set of keys used within the same context to
see if the same key has been used
3 - If it has an UPDATE is used.
4 - If not we do an ADD.
Reckon that sounds okay?
--
Navin Surtani
Intern Infinispan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
7:36 a.m.
New subject: [ISPN-548] Discussion on updating the QueryInterceptor to be able to update old keys
On 21/07/10 13:29, Israel Lacerra wrote:
Hi,
It's probably a question everyone knows the answer, but I'll ask anyway.
Make a UPDATE work on index, is not the same thing to do steps 2, 3 and
4? Or UPDATE is computationally more expensive? Or there is another
reason to avoid the UPDATE?
Not really as far as I know. Emmanuel would know this answer better. I
just wanted to have clarity from the other guys on the list before I
went in and made the change.
Israel
On Wed, Jul 21, 2010 at 8:54 AM, Navin Surtani <nsurtani(a)redhat.com
<mailto:nsurtani@redhat.com>> wrote:
Just getting a discussion going on this since a JIRA has now been
created.
Basically, the way I see it is that we can check which keys in the cache
have already been used - but that's context specific (I'll probably need
a quick explanation to how the InvocationContexts work). The question
for the gurus of ISPN here is whether or not this is going to be an
issue.
The plan of attack is as follows: -
1 - User does a put()
2 - Interceptor checks the set of keys used within the same context to
see if the same key has been used
3 - If it has an UPDATE is used.
4 - If not we do an ADD.
Reckon that sounds okay?
--
Navin Surtani
Intern Infinispan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Navin Surtani
Intern Infinispan
7:58 a.m.
New subject: [ISPN-548] Discussion on updating the QueryInterceptor to be able to update old keys
On 21 juil. 2010, at 14:36, Navin Surtani wrote:
> Make a UPDATE work on index, is not the same thing to do steps 2,
3 and
> 4? Or UPDATE is computationally more expensive? Or there is another
> reason to avoid the UPDATE?
Not really as far as I know. Emmanuel would know this answer better. I
just wanted to have clarity from the other guys on the list before I
went in and made the change.
UPDATE is really DELETE+INSERT
DELETE performs a query + marks the element as deleted
If we can avoid it by knowing that the key was already present the better.
I'm concerned about your description of #2
"2 - Interceptor checks the set of keys used within the same context to see if the
same key has been used"
WDYM by same context? same tx? if someones has a detached version of the entity from
another tx, he can reattach it on the same key and this has to be picked up as an UPDATE.
So it all depends if the index is stored locally or not. and whether the key lookup
requires a network roundtrip or not. I suspect the decision matrix is something like
that:
| Key lookup local | Key lookup remote
--------------------------------------------------------------------
Index local | do lookup | do UPDATE
Index remote | do lookup | do lookup
8:39 a.m.
New subject: [ISPN-548] Discussion on updating the QueryInterceptor to be able to update old keys
On 21/07/10 13:58, Emmanuel Bernard wrote:
I'm concerned about your description of #2
"2 - Interceptor checks the set of keys used within the same context to see if the
same key has been used"
WDYM by same context? same tx? if someones has a detached version of the entity from
another tx, he can reattach it on the same key and this has to be picked up as an UPDATE.
Well that's partly my issue. I don't think that a context is the same
thing as a transaction. One of the big ISPN pros will have a proper
answer and description to this point.
So it all depends if the index is stored locally or not. and whether
the key lookup requires a network roundtrip or not. I suspect the decision matrix is
something like that:
--
Navin Surtani
Intern Infinispan
8:51 a.m.
New subject: [ISPN-548] Discussion on updating the QueryInterceptor to be able to update old keys
On 21 Jul 2010, at 13:58, Emmanuel Bernard wrote:
On 21 juil. 2010, at 14:36, Navin Surtani wrote:
>> Make a UPDATE work on index, is not the same thing to do steps 2, 3 and
>> 4? Or UPDATE is computationally more expensive? Or there is another
>> reason to avoid the UPDATE?
>
> Not really as far as I know. Emmanuel would know this answer better. I
> just wanted to have clarity from the other guys on the list before I
> went in and made the change.
UPDATE is really DELETE+INSERT
DELETE performs a query + marks the element as deleted
If we can avoid it by knowing that the key was already present the better.
I'm concerned about your description of #2
"2 - Interceptor checks the set of keys used within the same context to see if the
same key has been used"
WDYM by same context? same tx? if someones has a detached version of the entity from
another tx, he can reattach it on the same key and this has to be picked up as an UPDATE.
If the discussion is about InvocationContext, which is passed to the
QueryInterceptor's method, then it means the transaction's context (assuming the
call is made in a tx's scope): it holds reference to all the locks acquired by the
given transaction, all the keys "touched" etc.
So it all depends if the index is stored locally or not. and whether the key lookup
requires a network roundtrip or not. I suspect the decision matrix is something like
that:
| Key lookup local | Key lookup remote
--------------------------------------------------------------------
Index local | do lookup | do UPDATE
Index remote | do lookup | do lookup
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:04 a.m.
On 21 Jul 2010, at 12:54, Navin Surtani wrote:
Just getting a discussion going on this since a JIRA has now been
created.
Basically, the way I see it is that we can check which keys in the cache
have already been used - but that's context specific (I'll probably need
a quick explanation to how the InvocationContexts work). The question
for the gurus of ISPN here is whether or not this is going to be an issue.
The plan of attack is as follows: -
1 - User does a put()
2 - Interceptor checks the set of keys used within the same context to
see if the same key has been used
That can be achieved through:
CacheEntry cacheEntry = ctx.lookupEntry(command.getKey());
The CacheEntry corresponds to a (key,value) pair in the cache.
Now, you can check the following:
1. (key,value) has been newly added?
cacheEntry.isCreated()
2. or is it just updated?
cacheEntry.isChanged()
3 - If it has an UPDATE is used.
4 - If not we do an ADD.
Reckon that sounds okay?
--
Navin Surtani
Intern Infinispan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
HTH,
Mircea
12:33 p.m.
New subject: [ISPN-548] Discussion on updating the QueryInterceptor to be able to update old keys
Hey all,
Just wanted to email the list saying that I've made the fix and the
QueryInterceptor should be able to make the call to the appropriate
Hibernate Search workType when required.
I've written up a test for it as well and all of the tests now pass.
Israel, if you could just grab the latest build from trunk and check it
with your code would be great. Once it all works for you then I will
back-port it with the 4.1 Branch and the fix will be available in
4.1.0.GA so you have a stable bug fux. Can you let me know asap?
Thanks for listening again!
--
Navin Surtani
Intern Infinispan
8:09 a.m.
On 21 Jul 2010, at 12:54, Navin Surtani wrote:
1 - User does a put()
2 - Interceptor checks the set of keys used within the same context to
see if the same key has been used
3 - If it has an UPDATE is used.
4 - If not we do an ADD.
Sorry, just saw this. To confirm, this should work even beyond the scope of a single
invocation, and even a single transaction, correct? E.g.,:
Tx1:
1) creates a NEW entry using cache.put()
2) new entry is indexed
Tx2 (potentially at a later date):
1) updates the entry using cache.put()
2) the index should be updated
So to that end, just checking the presence of the entry in the invocation context is not
good enough - all it will tell you is whether the entry was touched within the same scope
(whether that scope is an invocation or a transaction is irrelevant).
Mircea's solution of testing entry.isCreated() is a valid one.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
8:45 a.m.
Navin,
I update my trunk and I still have a little issue. But, maybe, it's a
problem in my code, cause I had to change the order of QueryInterceptor.
This line: cache.getAdvancedCache().addInterceptorAfter(inter,
LockingInterceptor.class); in QueryHelper did not work for me, because
somehow the LockingInterceptor was not in the interceptor chain yet.
Anyway, putting the same key twice:
"Key, value pairing is: - test + org.infinispan.query.Pessoa@2af8f5
Entry is created
Entry is changed
Key, value pairing is: - test + org.infinispan.query.Pessoa@1088a1b
Entry is changed"
entry.isChanged() is always returning true. But, like I said, maybe it's a
problem with my changes.
I will see it more carefully tomorrow...
Israel
On Thu, Jul 22, 2010 at 10:09 AM, Manik Surtani <manik(a)jboss.org> wrote:
On 21 Jul 2010, at 12:54, Navin Surtani wrote:
> 1 - User does a put()
> 2 - Interceptor checks the set of keys used within the same context to
> see if the same key has been used
> 3 - If it has an UPDATE is used.
> 4 - If not we do an ADD.
Sorry, just saw this. To confirm, this should work even beyond the scope
of a single invocation, and even a single transaction, correct? E.g.,:
Tx1:
1) creates a NEW entry using cache.put()
2) new entry is indexed
Tx2 (potentially at a later date):
1) updates the entry using cache.put()
2) the index should be updated
So to that end, just checking the presence of the entry in the invocation
context is not good enough - all it will tell you is whether the entry was
touched within the same scope (whether that scope is an invocation or a
transaction is irrelevant).
Mircea's solution of testing entry.isCreated() is a valid one.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:58 a.m.
entry.isChanged() returns true if the entry is, well, changed. Changed includes {created,
modified, removed}
entry.isCreated() only returns true if the entry has just been created in the scope of the
invocation.
See the Javadocs for details:
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
Cheers
Manik
On 22 Jul 2010, at 14:45, Israel Lacerra wrote:
Navin,
I update my trunk and I still have a little issue. But, maybe, it's a problem in my
code, cause I had to change the order of QueryInterceptor. This line:
cache.getAdvancedCache().addInterceptorAfter(inter, LockingInterceptor.class); in
QueryHelper did not work for me, because somehow the LockingInterceptor was not in the
interceptor chain yet.
Anyway, putting the same key twice:
"Key, value pairing is: - test + org.infinispan.query.Pessoa@2af8f5
Entry is created
Entry is changed
Key, value pairing is: - test + org.infinispan.query.Pessoa@1088a1b
Entry is changed"
entry.isChanged() is always returning true. But, like I said, maybe it's a problem
with my changes.
I will see it more carefully tomorrow...
Israel
On Thu, Jul 22, 2010 at 10:09 AM, Manik Surtani <manik(a)jboss.org> wrote:
On 21 Jul 2010, at 12:54, Navin Surtani wrote:
> 1 - User does a put()
> 2 - Interceptor checks the set of keys used within the same context to
> see if the same key has been used
> 3 - If it has an UPDATE is used.
> 4 - If not we do an ADD.
Sorry, just saw this. To confirm, this should work even beyond the scope of a single
invocation, and even a single transaction, correct? E.g.,:
Tx1:
1) creates a NEW entry using cache.put()
2) new entry is indexed
Tx2 (potentially at a later date):
1) updates the entry using cache.put()
2) the index should be updated
So to that end, just checking the presence of the entry in the invocation context is not
good enough - all it will tell you is whether the entry was touched within the same scope
(whether that scope is an invocation or a transaction is irrelevant).
Mircea's solution of testing entry.isCreated() is a valid one.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
9:19 a.m.
So, it is not a problem in my code.
Navin, changing the two ifs (if(entry.isCreated())...if(entry.isChanged()),
to if(entry.isCreated())/else my tests works fine.
thanks!
Israel
On Thu, Jul 22, 2010 at 10:58 AM, Manik Surtani <manik(a)jboss.org> wrote:
entry.isChanged() returns true if the entry is, well, changed.
Changed
includes {created, modified, removed}
entry.isCreated() only returns true if the entry has just been created in
the scope of the invocation.
See the Javadocs for details:
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
()
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
()
Cheers
Manik
On 22 Jul 2010, at 14:45, Israel Lacerra wrote:
Navin,
I update my trunk and I still have a little issue. But, maybe, it's a
problem in my code, cause I had to change the order of QueryInterceptor.
This line: cache.getAdvancedCache().addInterceptorAfter(inter,
LockingInterceptor.class); in QueryHelper did not work for me, because
somehow the LockingInterceptor was not in the interceptor chain yet.
Anyway, putting the same key twice:
"Key, value pairing is: - test + org.infinispan.query.Pessoa@2af8f5
Entry is created
Entry is changed
Key, value pairing is: - test + org.infinispan.query.Pessoa@1088a1b
Entry is changed"
entry.isChanged() is always returning true. But, like I said, maybe it's a
problem with my changes.
I will see it more carefully tomorrow...
Israel
On Thu, Jul 22, 2010 at 10:09 AM, Manik Surtani <manik(a)jboss.org> wrote:
>
> On 21 Jul 2010, at 12:54, Navin Surtani wrote:
>
> > 1 - User does a put()
> > 2 - Interceptor checks the set of keys used within the same context to
> > see if the same key has been used
> > 3 - If it has an UPDATE is used.
> > 4 - If not we do an ADD.
>
> Sorry, just saw this. To confirm, this should work even beyond the scope
> of a single invocation, and even a single transaction, correct? E.g.,:
>
> Tx1:
> 1) creates a NEW entry using cache.put()
> 2) new entry is indexed
>
> Tx2 (potentially at a later date):
> 1) updates the entry using cache.put()
> 2) the index should be updated
>
> So to that end, just checking the presence of the entry in the invocation
> context is not good enough - all it will tell you is whether the entry was
> touched within the same scope (whether that scope is an invocation or a
> transaction is irrelevant).
>
> Mircea's solution of testing entry.isCreated() is a valid one.
>
> Cheers
> Manik
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:31 a.m.
I'd recommend to also remove the System.outs floating around as well ;)
On 22 juil. 2010, at 16:19, Israel Lacerra wrote:
So, it is not a problem in my code.
Navin, changing the two ifs (if(entry.isCreated())...if(entry.isChanged()), to
if(entry.isCreated())/else my tests works fine.
thanks!
Israel
On Thu, Jul 22, 2010 at 10:58 AM, Manik Surtani <manik(a)jboss.org> wrote:
entry.isChanged() returns true if the entry is, well, changed. Changed includes
{created, modified, removed}
entry.isCreated() only returns true if the entry has just been created in the scope of
the invocation.
See the Javadocs for details:
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
Cheers
Manik
On 22 Jul 2010, at 14:45, Israel Lacerra wrote:
> Navin,
>
> I update my trunk and I still have a little issue. But, maybe, it's a problem in
my code, cause I had to change the order of QueryInterceptor. This line:
cache.getAdvancedCache().addInterceptorAfter(inter, LockingInterceptor.class); in
QueryHelper did not work for me, because somehow the LockingInterceptor was not in the
interceptor chain yet.
>
> Anyway, putting the same key twice:
>
> "Key, value pairing is: - test + org.infinispan.query.Pessoa@2af8f5
> Entry is created
> Entry is changed
> Key, value pairing is: - test + org.infinispan.query.Pessoa@1088a1b
> Entry is changed"
>
> entry.isChanged() is always returning true. But, like I said, maybe it's a
problem with my changes.
>
> I will see it more carefully tomorrow...
>
>
> Israel
>
> On Thu, Jul 22, 2010 at 10:09 AM, Manik Surtani <manik(a)jboss.org> wrote:
>
> On 21 Jul 2010, at 12:54, Navin Surtani wrote:
>
> > 1 - User does a put()
> > 2 - Interceptor checks the set of keys used within the same context to
> > see if the same key has been used
> > 3 - If it has an UPDATE is used.
> > 4 - If not we do an ADD.
>
> Sorry, just saw this. To confirm, this should work even beyond the scope of a single
invocation, and even a single transaction, correct? E.g.,:
>
> Tx1:
> 1) creates a NEW entry using cache.put()
> 2) new entry is indexed
>
> Tx2 (potentially at a later date):
> 1) updates the entry using cache.put()
> 2) the index should be updated
>
> So to that end, just checking the presence of the entry in the invocation context is
not good enough - all it will tell you is whether the entry was touched within the same
scope (whether that scope is an invocation or a transaction is irrelevant).
>
> Mircea's solution of testing entry.isCreated() is a valid one.
>
> Cheers
> Manik
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:56 p.m.
Yes - please, guys - no System.outs!! Use the logger if you need to.
On 22 Jul 2010, at 15:31, Emmanuel Bernard wrote:
I'd recommend to also remove the System.outs floating around as
well ;)
On 22 juil. 2010, at 16:19, Israel Lacerra wrote:
> So, it is not a problem in my code.
>
> Navin, changing the two ifs (if(entry.isCreated())...if(entry.isChanged()), to
if(entry.isCreated())/else my tests works fine.
>
> thanks!
> Israel
>
> On Thu, Jul 22, 2010 at 10:58 AM, Manik Surtani <manik(a)jboss.org> wrote:
> entry.isChanged() returns true if the entry is, well, changed. Changed includes
{created, modified, removed}
>
> entry.isCreated() only returns true if the entry has just been created in the scope
of the invocation.
>
> See the Javadocs for details:
>
>
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
>
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
>
> Cheers
> Manik
>
> On 22 Jul 2010, at 14:45, Israel Lacerra wrote:
>
>> Navin,
>>
>> I update my trunk and I still have a little issue. But, maybe, it's a problem
in my code, cause I had to change the order of QueryInterceptor. This line:
cache.getAdvancedCache().addInterceptorAfter(inter, LockingInterceptor.class); in
QueryHelper did not work for me, because somehow the LockingInterceptor was not in the
interceptor chain yet.
>>
>> Anyway, putting the same key twice:
>>
>> "Key, value pairing is: - test + org.infinispan.query.Pessoa@2af8f5
>> Entry is created
>> Entry is changed
>> Key, value pairing is: - test + org.infinispan.query.Pessoa@1088a1b
>> Entry is changed"
>>
>> entry.isChanged() is always returning true. But, like I said, maybe it's a
problem with my changes.
>>
>> I will see it more carefully tomorrow...
>>
>>
>> Israel
>>
>> On Thu, Jul 22, 2010 at 10:09 AM, Manik Surtani <manik(a)jboss.org> wrote:
>>
>> On 21 Jul 2010, at 12:54, Navin Surtani wrote:
>>
>> > 1 - User does a put()
>> > 2 - Interceptor checks the set of keys used within the same context to
>> > see if the same key has been used
>> > 3 - If it has an UPDATE is used.
>> > 4 - If not we do an ADD.
>>
>> Sorry, just saw this. To confirm, this should work even beyond the scope of a
single invocation, and even a single transaction, correct? E.g.,:
>>
>> Tx1:
>> 1) creates a NEW entry using cache.put()
>> 2) new entry is indexed
>>
>> Tx2 (potentially at a later date):
>> 1) updates the entry using cache.put()
>> 2) the index should be updated
>>
>> So to that end, just checking the presence of the entry in the invocation context
is not good enough - all it will tell you is whether the entry was touched within the same
scope (whether that scope is an invocation or a transaction is irrelevant).
>>
>> Mircea's solution of testing entry.isCreated() is a valid one.
>>
>> Cheers
>> Manik
>>
>> --
>> Manik Surtani
>> manik(a)jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
4:58 a.m.
New subject: [ISPN-548] Discussion on updating the QueryInterceptor to be able to update old keys
On 22/07/10 18:56, Manik Surtani wrote:
Yes - please, guys - no System.outs!! Use the logger if you need to.
Yeah I know it was just made for easy debugging. I should have removed
it before I committed. I'll go fix that now.
On 22 Jul 2010, at 15:31, Emmanuel Bernard wrote:
> I'd recommend to also remove the System.outs floating around as well ;)
>
> On 22 juil. 2010, at 16:19, Israel Lacerra wrote:
>
>> So, it is not a problem in my code.
>>
>> Navin, changing the two ifs
>> (if(entry.isCreated())...if(entry.isChanged()), to
>> if(entry.isCreated())/else my tests works fine.
>>
>> thanks!
>> Israel
>>
>> On Thu, Jul 22, 2010 at 10:58 AM, Manik Surtani <manik(a)jboss.org
>> <mailto:manik@jboss.org>> wrote:
>>
>> entry.isChanged() returns true if the entry is, well, changed.
>> Changed includes {created, modified, removed}
>>
>> entry.isCreated() only returns true if the entry has just been
>> created in the scope of the invocation.
>>
>> See the Javadocs for details:
>>
>>
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
>>
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent...
>>
>> Cheers
>> Manik
>>
>> On 22 Jul 2010, at 14:45, Israel Lacerra wrote:
>>
>>> Navin,
>>>
>>> I update my trunk and I still have a little issue. But, maybe,
>>> it's a problem in my code, cause I had to change the order of
>>> QueryInterceptor. This line:
>>> cache.getAdvancedCache().addInterceptorAfter(inter,
>>> LockingInterceptor.class); in QueryHelper did not work for me,
>>> because somehow the LockingInterceptor was not in the
>>> interceptor chain yet.
>>>
>>> Anyway, putting the same key twice:
>>>
>>> "Key, value pairing is: - test + org.infinispan.query.Pessoa@2af8f5
>>> Entry is created
>>> Entry is changed
>>> Key, value pairing is: - test + org.infinispan.query.Pessoa@1088a1b
>>> Entry is changed"
>>>
>>> entry.isChanged() is always returning true. But, like I said,
>>> maybe it's a problem with my changes.
>>>
>>> I will see it more carefully tomorrow...
>>>
>>>
>>> Israel
>>>
>>> On Thu, Jul 22, 2010 at 10:09 AM, Manik Surtani <manik(a)jboss.org
>>> <mailto:manik@jboss.org>> wrote:
>>>
>>>
>>> On 21 Jul 2010, at 12:54, Navin Surtani wrote:
>>>
>>> > 1 - User does a put()
>>> > 2 - Interceptor checks the set of keys used within the
>>> same context to
>>> > see if the same key has been used
>>> > 3 - If it has an UPDATE is used.
>>> > 4 - If not we do an ADD.
>>>
>>> Sorry, just saw this. To confirm, this should work even
>>> beyond the scope of a single invocation, and even a single
>>> transaction, correct? E.g.,:
>>>
>>> Tx1:
>>> 1) creates a NEW entry using cache.put()
>>> 2) new entry is indexed
>>>
>>> Tx2 (potentially at a later date):
>>> 1) updates the entry using cache.put()
>>> 2) the index should be updated
>>>
>>> So to that end, just checking the presence of the entry in
>>> the invocation context is not good enough - all it will tell
>>> you is whether the entry was touched within the same scope
>>> (whether that scope is an invocation or a transaction is
>>> irrelevant).
>>>
>>> Mircea's solution of testing entry.isCreated() is a valid one.
>>>
>>> Cheers
>>> Manik
>>>
>>> --
>>> Manik Surtani
>>> manik(a)jboss.org <mailto:manik@jboss.org>
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org <http://www.infinispan.org/>
>>> http://www.jbosscache.org <http://www.jbosscache.org/>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> <mailto:infinispan-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> <mailto:infinispan-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> manik(a)jboss.org <mailto:manik@jboss.org>
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org <http://www.infinispan.org/>
>> http://www.jbosscache.org <http://www.jbosscache.org/>
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> <mailto:infinispan-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org <mailto:manik@jboss.org>
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Navin Surtani
Intern Infinispan
5189
days inactive
5191
days old
infinispan-dev@lists.jboss.org
14 comments
5 participants
participants (5)
-
Emmanuel Bernard -
Israel Lacerra -
Manik Surtani -
Mircea Markus -
Navin Surtani