Do I need to lock a table during a FLUSH when using VSDK C++ API in multi-threaded app?

[Matthew Jew]

On Aug 16, 2006, at 3:27 AM, Ivan Smahin wrote:

> Hello Matthew,
>
> Wednesday, August 16, 2006, 1:24:34 PM, you wrote:
>
>> On Aug 16, 2006, at 3:16 AM, Ivan Smahin wrote:
>
>>> Hello Matthew,
>>>
>>> Wednesday, August 16, 2006, 1:06:55 PM, you wrote:
>>>
>>>> My understanding was that there was some support for multiple  
>>>> threads
>>>> in version 2 of Valentina. If not, what is the point of record
>>>> locking?
>>>
>>> Record  locking prevent to get access to locked records using
>>> different
>>> cursors.
>>>
>>>> What exactly has changed from version 1 to version 2 of VSDK  
>>>> related
>>>> to multi-thread support? Anything? Version 1 required me to lock  
>>>> the
>>>> entire Valentina engine, so that only one thread at a time could do
>>>> a Valentina call. Has this changed in version 2 or not? It was my
>>>> understanding
>>>> that it had. What is the story?
>>>
>>> This  task (and transactions) is still in process. Where have you  
>>> read
>>> about multithreading in V2?
>>>
>
>> So is it still true that I must have a global lock/semaphore to
>> control access
>> to the entire Valentina engine? (So that only one thread at a time
>> can make
>> any calls to Valentina?)
>
> It will be 100% safe.
> We hope we will get the multi-threaded solution ASAP.
>

What does "It will be 100% safe" mean?

I asked if I still need to lock the entire engine, and I was hoping
for either "yes" or "no".

I know that if I *do* lock the entire engine that it will be 100% safe;
that is not new information. What I need to know is if I *must* lock
the entire engine. I do not want to have to lock the entire engine if I
do not have to. My usage is very heavily multi-threaded, and if I  
have to
lock the entire engine, I will lose much of the speed and benefits of  
the multiple
threads. I do not have a choice about having multiple threads because my
application is handling many simultaneous queries from many  
simultaneous clients.

- Matthew