Pavel,
I do not have a requirement of persistence in my current design, but I
expect that we might extend this shared-queue solution to more areas of the
server and will require some sort of persistence then.
That is one of the main reasons I do not want to use IPC queues (there are
other reasons
to do its job - you need to have your
database in the file system even if you won't ever read it once your
application is closed.
Pavel
On Mon, May 10, 2010 at 3:59 PM, Manuj Bhatia manujbha...@gmail.com
wrote:
Pavel,
I do not have a requirement of persistence in my current design
. If the
performance is not satisfactory, then I might look at implementing a VFS.
Thanks,
~Manuj
On Tue, May 11, 2010 at 8:39 AM, Eric Smith eas@gmail.com wrote:
Manuj Bhatia wrote:
I do not have a requirement of persistence in my current design, but I
expect that we might extend
I need to exchange messages across processes, not threads. And one of the
reasons that I am inclined towards SQLite is that I do not want a separate
Queue-manager process.
I'll just write wrapper APIs around SQLite and embed them into each
application, so I have a manager-less implementation.
I
Hi,
I am trying to implement a shared queue (to asynchronously exchange messages
between processes) using SQLite.
Since I do not need my queues to be persistent (at least for now), I do not
want to use disk based SQLite database (for better performance).
I see there is an option to create purely
