Good to know if we start hitting bottlenecks down the road. FWIW, our
app isn't really IO-bound, so I don't *think* that'll ever be a
problem, but who knows.
Thanks,
- Chas
On Oct 22, 2009, at 11:16 AM, Bryan Thompson wrote:
Chas, it has been a long time since I looked at the code, but I
believe that there will be redundent caching in jdbm and you may
wind up paying for redundant IOs because you are not reusing the
same cache. -bryan
From: Chas Emerick [mailto:[email protected]]
Sent: Thursday, October 22, 2009 11:14 AM
To: Bryan Thompson
Cc: 'Alex Boisvert'; 'JDBM General listserv'
Subject: Re: [Jdbm-general] Read concurrency clarification
Simplicity of implementation. If I've got a number of totally
separate modules that are read-only, there's no reason to introduce
any kind of coordination ceremony if multiple readers are safe
(which, by all rights, should be a given for any data store).
- Chas
On Oct 22, 2009, at 10:59 AM, Bryan Thompson wrote:
I believe that the B+Tree tuple cursor is unsafe under concurrent
read -- that is, updates to its internal state are not thread safe.
Why would you use more than one recman instance for a given store
in the same JVM?
-bryan
From: Chas Emerick [mailto:[email protected]]
Sent: Thursday, October 22, 2009 10:45 AM
To: Alex Boisvert
Cc: JDBM General listserv
Subject: Re: [Jdbm-general] Read concurrency clarification
Right, which happens to be my situation: many concurrent reads from
different threads, and when a write needs to be done, we lock
globally.
Thanks for the (extended) clarification :-)
- Chas
On Oct 22, 2009, at 10:41 AM, Alex Boisvert wrote:
No, that's not safe at all.... unless all the access is read-only.
alex
On Thu, Oct 22, 2009 at 7:36 AM, Chas Emerick
<[email protected]> wrote:
Alex,
Thank you for the clarification. Just to make sure we're
understanding each other, I'm actually asking about multiple
readers, each opening and using their own RecordManagers. Your
mention of synchronization leads me to think you're talking about
multiple threads reading from a single RecordManager.
Just FYI, I'm being careful here because I came across a mention
of RM changing files on disk when *reading*, which surprised me
(can't find the link right now)...
Thanks again,
- Chas
On Oct 22, 2009, at 10:27 AM, Alex Boisvert wrote:
Individual concurrent reads are safe. Pretty much everything is
synchronized at the top of level.
However, iterators / tuple browsers are unsafe under concurrent
updates. You would have to synchronize on the RecordManager
instance to maintain a consistent view while iterating.
alex
On Thu, Oct 22, 2009 at 5:10 AM, Chas Emerick <[email protected]
> wrote:
I've been plumbing around the list archives for a while, but
they're
something of a jumble (thanks, Sourceforge!), so I figured I'd
open a
new thread to ask:
What level of read concurrency does jdbm support?
What seems clear is that, to be safe, there should only be one
thread
writing to a jdbm database (although it appears that it is possible
for multiple threads to participate in a transaction, I'm perfectly
fine with serializing all write access). However, I came across at
least a number of comments that lead me to believe that concurrent
reads are unsafe as well, although they're all from pre-history
(e.g.
2001).
Thanks,
- Chas
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF,
CA
is the only developer event you need to attend this year.
Jumpstart your
developing skills, take BlackBerry mobile applications to market
and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register
now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jdbm-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jdbm-general
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jdbm-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jdbm-general
