Yes it looks like a SharedQueue is not meant to be used as a persistent
queue ... it is meant as a shared queue for multiple GsProcess instances
in a single gem.
If you want to have a persistent FIFO queue with multiple producers and
a single consumer then an RcQueue is appropriate.
If you are going to have multiple consumers (your use case), then I
think that you can use an RcQueue if you use an object lock on the
RcQueue, to guarantee that there is a only a single gem removing objects
from the queue (single consumer). Take a look at System
class>>_lock:kind:autoRelease: (with kind > 5),
See System class>>waitForRcWriteLock: for an example where the gem will
wait until the lock is available --- useful if you have multiple gems
dedicated to removing entries from the queue processing.
On 3/25/17 1:22 PM, PAUL DEBRUICKER via Glass wrote:
> In tODE, on GS 3.3.3, when I attempt to store a new empty SharedQueue in a class var I get this error:
> a TransactionError occurred (error 2407), The object Semaphore(72376689153) may not be committed, 'instances of its class are non-persistent'
> I'm trying to use it because I'd like to have multiple gems removing/processing elements from the queue and committing their changes to them independently.
> I just need to add elements to the queue once. So maybe another class is more appropriate?
> Glass mailing list
> [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass