You mean using the same cursor in different threads? If so, yes.
Different cursors in different threads should be safe provided all access is
read-only.
alex
On Thu, Oct 22, 2009 at 7:59 AM, Bryan Thompson <[email protected]> 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
