[sqlite] Calling ATTACH internally

2007-01-04 Thread BardzoTajneKonto

Hi
 
I need SQLite to be able to acces several tables at the same time. I'v decided 
to do this by creating a new database for each table. So far I'v changed 
sqlite3StartTable() function - it calls attachFunc() and then changes name to 
name.name. It worked - master database is not changed, and new table is created 
in just created database. But I had to disable sqlite3SafetyOn() check. Can I 
assume that I'm in the same thread that set SQLITE_MAGIC_BUSY and it is safe to 
disable checking when calling attachFunc() from sqlite3StartTable() (and 
probably from every other funtions that uses table name, since I think I'll 
have to do this for every SELECT, INSERT, etc.) ?
Also I'm wandering about SQLite reliability. For example comment to 
sqlite3SafetyOn() says: 
** This routine is a attempt to detect if two threads use the
** same sqlite* pointer at the same time. There is a race 
** condition so it is possible that the error is not detected.
** But usually the problem will be seen.
The race codidion is obvious, so is the solution, especially since the are 
already platform independed mutexes in SQlite. Another comment:
** The lock byte is obtained at 
** random so two separate readers can probably access the file at the 
** same time, unless they are unlucky and choose the same lock byte.
can probably access the file at the same time is better than can't access, 
but there is no guarantee.
Does commets like those mean that SQLite will work very often, but there are 
known bugs not resolved because thay are unlikely to appear, or problems like 
race conditions are guarented to be found is some other functions?
 
Wiktor Adamski



-
To unsubscribe, send email to [EMAIL PROTECTED]
-



Re: [sqlite] Calling ATTACH internally

2007-01-04 Thread Joe Wilson
 ** The lock byte is obtained at 
 ** random so two separate readers can probably access the file at the 
 ** same time, unless they are unlucky and choose the same lock byte.
 can probably access the file at the same time is better than can't 
 access, but there is no
 guarantee.
 Does commets like those mean that SQLite will work very often, but there are 
 known bugs not
 resolved because thay are unlikely to appear, or problems like race 
 conditions are guarented to
 be found is some other functions?

I'm not 100% sure what you're trying to do, but in the specific 
case of SHARED_LOCK, I think in the rare case if 2 readers happen 
to pick the same lock byte at random, one reader will simply block 
until the other is done with it. It's certainly not a potential bug 
even if the same lock byte is chosen, it would just slow it down by
forcing access to be serialized.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-