I haven't used that yet but it'll be a great addition once the kinks are worked out. Currently, I still use polls once a second, and then my server app handles all the other stuff. Eventually, I will try switching to live query. I have some classes where I poll by (datetime > lastprocessedTm). I have others that are more demanding (@rid > lastRid). This works great on a single node, and I'm happy to have confirmed that it can also run that way in distributed mode (increasing availability and persistence) as long as I use the default cluster.
If I did need to add an additional counter, I was playing around with this, which while adding more complexity should have also worked (though I was getting an exception for some reason): https://github.com/orientechnologies/orientdb/issues/4316 - for a high-volume situation where maximizing sharding is helpful, that may still be a better approach (or this as well, however Yet Another Thing To Learn): http://doc.gridgain.org/latest/Distributed+AtomicSequence But, as you can figure that synchronization would neutralize a good bit of the advantages of sharding in this usage case. -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
