Re: Fwd: new atomicCounter support (OAK-2220)

[Davide Giannella <da...@apache.org>]

On 21/12/2015 14:17, Torgeir Veimo wrote:
> Can someone confirm if the atomic counter support code is suitable for
> sequences?
>
I think on Segment it can safely be used but not on a mongo cluster.

What the atomic counter ensure is that the amount of
increments/decrements is consistent from a persistence POV no matter the
number of concurrent operations you're pushing in.

While the sequence use case is more like: give me the next available
value. it's definitely a good starting point on top of which you can
build a sequence mechanism.

if we speak of single instance Segment only, you can opt for an
application side lock in which you put in the increments and fetch of
the value.  Something like:

public static long nextSeq(String p, Session s) {
  // ... fecthing of the node by path `p`
  // initiate application side lock
  session.refresh(); // fetch whatever may come from other MVCC
  counter.setProperty("oak:increment", 1);
  session.save();
  long seq =  counter.getProperty(...).getLong();
  // release lock
  return seq;
}

As said, on segment ONLY, it should work fairly fine.

It won't work on a mongo clustered instance as the cluster nodes
alignment is asynchronous and because of OAK-2472. So to be put in
words, you may have the same sequence returned by two different cluster
nodes.

HTH
Davide

Re: Fwd: new atomicCounter support (OAK-2220)

[Davide Giannella <da...@apache.org>]

On 13/01/2016 06:21, Torgeir Veimo wrote:
> Is there any plans to introduce a cluster safe mechanism of providing
> unique counter values?
>
> Most applications where a sequence is used doesn't require full
> sequentiality, but rather a unique number that is easier to memorize /
> write than uuids for humans. So a type similar to mongodbs ObjectId type
> would be sufficient:
>
> https://docs.mongodb.org/manual/reference/object-id/
>
>
Not that I'm aware of. But please feel free to file a jira ticket for an
improvements providing as much details as possible around the requirements.

Cheers
Davide

Re: Fwd: new atomicCounter support (OAK-2220)

[Torgeir Veimo <to...@gmail.com>]

Is there any plans to introduce a cluster safe mechanism of providing
unique counter values?

Most applications where a sequence is used doesn't require full
sequentiality, but rather a unique number that is easier to memorize /
write than uuids for humans. So a type similar to mongodbs ObjectId type
would be sufficient:

https://docs.mongodb.org/manual/reference/object-id/



On 4 January 2016 at 20:35, Davide Giannella <da...@apache.org> wrote:

> On 21/12/2015 14:17, Torgeir Veimo wrote:
> > Can someone confirm if the atomic counter support code is suitable for
> > sequences?
> >
> I think on Segment it can safely be used but not on a mongo cluster.
>
> What the atomic counter ensure is that the amount of
> increments/decrements is consistent from a persistence POV no matter the
> number of concurrent operations you're pushing in.
>
> While the sequence use case is more like: give me the next available
> value. it's definitely a good starting point on top of which you can
> build a sequence mechanism.
>
> if we speak of single instance Segment only, you can opt for an
> application side lock in which you put in the increments and fetch of
> the value.  Something like:
>
> public static long nextSeq(String p, Session s) {
>   // ... fecthing of the node by path `p`
>   // initiate application side lock
>   session.refresh(); // fetch whatever may come from other MVCC
>   counter.setProperty("oak:increment", 1);
>   session.save();
>   long seq =  counter.getProperty(...).getLong();
>   // release lock
>   return seq;
> }
>
> As said, on segment ONLY, it should work fairly fine.
>
> It won't work on a mongo clustered instance as the cluster nodes
> alignment is asynchronous and because of OAK-2472. So to be put in
> words, you may have the same sequence returned by two different cluster
> nodes.
>
> HTH
> Davide
>



-- 
-Tor