Re: Fwd: new atomicCounter support (OAK-2220)
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)
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 Giannellawrote: > 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
Re: Fwd: new atomicCounter support (OAK-2220)
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
Fwd: new atomicCounter support (OAK-2220)
Can someone confirm if the atomic counter support code is suitable for sequences? https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/atomic/AtomicCounterEditor.html If my reading of the spec is correct, separate sessions will see their results from the increment immediately and isolated from other sessions incrementing the same counter, so using the results from an increment can safely be used as a sequence number as long as the counter is ever incremented in any code? On 13 November 2015 at 14:40, Torgeir Veimowrote: > Am trying to use the new atomicSupport feature, and am wondering if I'm > using it the correct way; > > My counter is initialised with > > Node counter = JcrUtils.getOrCreateByPath("/testCounter", > "oak:Unstructured", session); > if (counter.isNew()) { > counter.addMixin("mix:atomicCounter"); > session.save(); > } > > then when fetching a new value > > counter.setProperty("oak:increment", 1); > session.save(); > long value = counter.getProperty("oak:counter").getLong(); > > What happens if the same code is called from a different thread / session > after the session.save() but before the getProperty() call? Will the value > remain unchanged in this thread / session? > > -- > -Tor > -- -Tor -- -Tor