On 4 Jul 2011, at 07:57, Galder Zamarreño wrote:
I get the feeling that those atomic operations are particularly useful when
transactions are not used cos they allow you to reduce to cache operations to
one, hence avoiding the need to use a lock or synchronized block, or in our
case, a
On 5 Jul 2011, at 10:23, Galder Zamarreño wrote:
I've gone through some cases and end results would not differ at first glance
if the atomic ops suspend the txs. The only thing that would change would be
the expectations of lock acquisition timeouts by atomic ops within txs.
There is also
On 11 Jul 2011, at 10:45, Manik Surtani wrote:
On 4 Jul 2011, at 07:57, Galder Zamarreño wrote:
I get the feeling that those atomic operations are particularly useful when
transactions are not used cos they allow you to reduce to cache operations
to one, hence avoiding the need to use
On 11 Jul 2011, at 13:21, Mircea Markus wrote:
On 11 Jul 2011, at 10:45, Manik Surtani wrote:
On 4 Jul 2011, at 07:57, Galder Zamarreño wrote:
I get the feeling that those atomic operations are particularly useful when
transactions are not used cos they allow you to reduce to cache
On 4 Jul 2011, at 07:57, Galder Zamarreño wrote:
Do these atomic operations really make sense within an (optimitic)
transaction?
For example, putIfAbsent(): it stores a k,v pair if the key is not present.
But the key about it's usability is that the return of putIfAbsent can tell
you
As we where still unsure about the use cases, here comes the first
user attempting to use it:
http://community.jboss.org/thread/168998?tstart=0
Cheers,
Sanne
2011/7/8 Mircea Markus mircea.mar...@jboss.com:
On 5 Jul 2011, at 10:45, Dan Berindei wrote:
On Tue, Jul 5, 2011 at 12:23 PM, Galder
On 5 Jul 2011, at 11:39, Sanne Grinovero wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
On Tue, Jul 5, 2011 at 12:46 PM, Sanne Grinovero sa...@infinispan.org
wrote:
2011/7/5 Galder Zamarreño gal...@redhat.com:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they
On 5 Jul 2011, at 14:04, Sanne Grinovero wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
On Tue, Jul 5, 2011 at 1:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
Here is a contrived example:
1. Start tx Tx1
2. cache.get(k) - v0
3.
On 5 Jul 2011, at 11:45, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Jul 5, 2011 at 12:23 PM, Galder Zamarreño gal...@redhat.com wrote:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I admit I was expecting them to
just work: the API is there, nice public methods in the public
interface with javadocs explaining that
On Tue, Jul 5, 2011 at 12:23 PM, Galder Zamarreño gal...@redhat.com wrote:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I admit I was expecting them to
just work: the API is there,
2011/7/5 Galder Zamarreño gal...@redhat.com:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I admit I was expecting them to
just work: the API is there, nice public methods in the
2011/7/5 Dan Berindei dan.berin...@gmail.com:
On Tue, Jul 5, 2011 at 12:23 PM, Galder Zamarreño gal...@redhat.com wrote:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I admit I was
On Tue, Jul 5, 2011 at 12:49 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
After all Sanne has two use cases for atomic operations: sequences and
reference counts. Sequences can and should happen outside
transactions, but as we discussed on the
On Tue, Jul 5, 2011 at 12:46 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Galder Zamarreño gal...@redhat.com:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I admit I was
2011/7/5 Dan Berindei dan.berin...@gmail.com:
On Tue, Jul 5, 2011 at 12:46 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Galder Zamarreño gal...@redhat.com:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
On Tue, Jul 5, 2011 at 1:45 PM, Sanne Grinovero sa...@infinispan.org wrote:
That's an interesting case, but I wasn't thinking about that. So it
might become useful later on.
The refcount scenario I'd like to improve first is about garbage
collection of old unused index segments,
we're
On Tue, Jul 5, 2011 at 1:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
Here is a contrived example:
1. Start tx Tx1
2. cache.get(k) - v0
3. cache.replace(k, v0, v1)
4. gache.get(k) - ??
With repeatable read and suspend/resume around
On Jul 5, 2011, at 11:45 AM, Dan Berindei wrote:
On Tue, Jul 5, 2011 at 12:23 PM, Galder Zamarreño gal...@redhat.com wrote:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I
On Jul 5, 2011, at 11:46 AM, Sanne Grinovero wrote:
2011/7/5 Galder Zamarreño gal...@redhat.com:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I admit I was expecting them to
2011/7/5 Dan Berindei dan.berin...@gmail.com:
On Tue, Jul 5, 2011 at 1:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
Here is a contrived example:
1. Start tx Tx1
2. cache.get(k) - v0
3. cache.replace(k, v0, v1)
4. gache.get(k) - ??
With
On Jul 5, 2011, at 1:24 PM, Dan Berindei wrote:
On Tue, Jul 5, 2011 at 1:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
Here is a contrived example:
1. Start tx Tx1
2. cache.get(k) - v0
3. cache.replace(k, v0, v1)
4. gache.get(k) - ??
Email summary:
Number of lines: 188
Number of useful lines (Strict): 1 (0,53%)
Number of useful line (contextual): 12 (6.3%)
Position of the useful line in the amount of data: 57 (had to scroll 30% of the
data to find it and the addition 70% as I was not sure another one wasn't lost
somewhere
On Tue, Jul 5, 2011 at 4:04 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
On Tue, Jul 5, 2011 at 1:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
Here is a contrived example:
1. Start tx Tx1
2.
Do these atomic operations really make sense within an (optimitic) transaction?
For example, putIfAbsent(): it stores a k,v pair if the key is not present. But
the key about it's usability is that the return of putIfAbsent can tell you
whether the put succeeded or not.
Once you go into
I agree they don't make sense, but only in the sense of exposed API
during a transaction: some time ago I admit I was expecting them to
just work: the API is there, nice public methods in the public
interface with javadocs explaining that that was exactly what I was
looking for, no warnings, no
26 matches
Mail list logo
