2 Replies Latest reply: Mar 2, 2012 1:35 PM by 906078 RSS

    Best way to implement a QUEUE of VARIABLE LENGTH records?

      Hi there,

      I see that the built in QUEUE access method only allows for fixed length records. What would you suggest is the best way to implement a "variable length" queue using Berkeley DB? Something that could hold JPG's etc. Perhaps use the RECNO access method? What does is mean that the RECNO has "Fixed or mutable record numbers"? Do you have to say what the MAX number of recs is upfront?

      Any help or advice would be greatly appreciated ;-)

        • 1. Re: Best way to implement a QUEUE of VARIABLE LENGTH records?
          Oracle, Sandra Whitman

          I would start by reviewing the, "Access Method Configuration" documentation
          at: http://docs.oracle.com/cd/E17076_02/html/programmer_reference/am_conf.html#am_conf_intro

          That documentation describes each of the access methods as well as the criteria for

          • 2. Re: Best way to implement a QUEUE of VARIABLE LENGTH records?
            If you want a queue of variable-length records you could do the following:
            1) Create a hash table holding your jpeg's.
            The key should be a fixed-size record. (Perhaps the md5 of the jpeg or something).
            The value would be the jpeg.
            2) Store the key from (1) in a queue.

            Perhaps you don't really need a queue. You could simply create a B-tree in which the key is a incrementing counter, and the value is the jpeg. To insert, fetch the DB_LASt itemfrom the B-tree, increment the key that you find there, and do a DB->put adding to the end of the tree To remove, fetch the DB_FIRST item from the B-tree. The advantage of the queue over this simple B-tree is that the queue has more concurrency. If your application doesn't need much concurrency, a simple B-tree solution might be good enough.

            I'm not a real expert on the Berkeley DB, and maybe you can find better advice than mine... It would be great if someone who actually knows this stuff would confirm what I'm saying or contradict me!