transactional queue

Discussion in 'Java' started by, Mar 2, 2006.

  1. Guest


    I'm trying to look for a transactional queue implementation.

    >From what I understand, during the dequeue operation, a commit doesn't

    happen until the client code calls commit eventhough the client code
    uses the elements it has dequeued but not yet committed.

    , Mar 2, 2006
    1. Advertisements

  2. bob

    bob Guest

    Facets™ is an object oriented database that provides transactional,
    easy to implement, highly scalable transparent persistence by
    reachability for native Java™ objects. Facets includes a class
    called CuQueue. Objects can be added to the CuQueue at one end by one
    or more sessions (called "producers"). Objects can be consumed at the
    other end in FIFO order by a single concurrent session (called the
    "consumer"). There can be multiple consumers, but not concurrently. The
    consumer can also be a producer during the same transaction.

    More details about Facets and a free download are available at
    bob, Mar 2, 2006
    1. Advertisements

  3. What should, in your opinion, happen if two threads request an object
    concurrently, before either commits to dequeuing it?

    [A, B, C]

    Thread a:
    poll(); <--- Will receive A

    /* do stuff */


    Thread b:
    poll() <--- What should it receive, if calling between poll() and
    Stefan Schulz, Mar 2, 2006
  4. bob

    bob Guest

    The Facets oodb by default uses optimistic concurrency with each
    transaction being given a guaranteed view of the database (it does not
    see changes made by another transaction until that transaction
    commits). So in the example you described with both threads a and b
    starting from the same transactional view of the database the first
    thread to commit (thread a) wins and removes object A. Thread b also
    attempts to remove A (because it has the same view), but it fails in
    the consistency checks at commit.

    If you want to have multiple consumers from the queue there are at
    least two solutions:
    1. Use the ObjectLocking feature to serialize the consumers.
    2. Use multiple CuQueues (one for each Consumer thread) with some
    other heuristic of the application being used by the producers
    to determine which queue to put their entries in.

    A CuQueue is a Java class which provides a queue interface but is
    implemented with behavioral concurrency control. The behavioral
    concurrency control allows multiple producers to run concurrently with
    a single consumer with no transaction conflicts. Therefore, using a
    CuQueue for each consumer thread allows the construction of a system in
    which multiple producers and consumers are able to run concurrently
    with no transaction conflicts. This solution is better than the
    pessimistic approach (using ObjectLocks) because it doesn't force the
    serialization of the threads that are servicing the queue.
    bob, Mar 3, 2006
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul L. Du Bois

    Queue.Queue-like class without the busy-wait

    Paul L. Du Bois, Mar 24, 2005, in forum: Python
    Antoon Pardon
    Apr 4, 2005
  2. Russell Warren

    Is Queue.Queue.queue.clear() thread-safe?

    Russell Warren, Jun 22, 2006, in forum: Python
    Russell Warren
    Jun 27, 2006
  3. Kceiw
    Jim Langston
    Mar 14, 2006
  4. Gabriel Rossetti
    Jerry Hill
    Apr 25, 2008
  5. Kris

Share This Page