> make every single sql execution follow this logic
>
> die 'nested lock' if global_recursion_flag
>
> global_recursion_flag = true
>
> ret = flock 'db.lock', LOCK_EX
> die 'lock failed' unless ret
>
> result = execute sql
>
> ret = flock 'db.lock', LOCK_UN
> die 'unlock failed' unless ret
>
> global_recursion_flag = false
I can't really make that because in PHP i can't set a global variable
that will be available for anyone that uses the script. If i set a
variable and change it in the script the next one that runs the script
will have the unchanged variable... I can't set a variable that will
be valid across users...
I did the closest i could to what you wrote and need i say? the
database got locked again :(
I checked all the scripts to be sure that every script uses the class
and there are no scripts that don't use the class... so 1) is excluded
can you explain more 2) i could't understand it right what do you mean
by :" fcntl based locks are process based so all thread 'get the lock'
" I don't know how exactly are working apache and PHP under Linux but
i suppose that the whole PHP is one process and every script is run as
a thread... so as a man opens the site a new thread is run for the
script he opened so yes the access is multythreaded as any web site.
I also tried that:
database - seriously, if you coordinated ALL access through something like
>
> ret = flock 'db.lock', LOCK_EX
>
> mv '.db', 'db'
>
> result = execute sql
>
> mv 'db', '.db'
>
> ret = flock 'db.lock', LOCK_UN
>
(or at least i tried to try it) but it seems that i can't rename the
database until the database is opened and it opens at the beggining of
every script and closes at the end so i can't rename the database in
the middle of the script because the database is opened and it doesn't
let me.
I added writing to file if the .lock file is locked but there is
nothing in the file so the .lock file is not locked and that means (at
least i think so) that the database shouldn't be locked by my script
but by some other process or am i wrong?
> > I tried not to commit a transaction but the database didn't lock... any
> > ideas?
I think it didn't lock because the PHP closes the database when the
script finishes and automatically commits.
> this smells fishy. obviously SOMETHING changed right?
Yes i agree that something changed what i meant is that i didn't
change the script with the recursion that was working and is still
working all the time because it's one of the most visited
Today i asked from the hosting the access log lines that include my
database file but there was only the ftp process acesssing the file i
thought that the PHP also must be listed there as process but it
wasn't there?? How is that possible? Why isn't it there?
Thank you I will wait more explanations on 2) but for now it seems to
me that it's 0) that is the most possible choice.
On Mon, 29 Nov 2004 16:08:39 -0700 (MST), Ara.T.Howard
<[EMAIL PROTECTED]> wrote:
> On Tue, 30 Nov 2004, Alexander Jordanov wrote:
>
> > I am 100% sure that my all my queries go trought that class. Unfortunatelly
> > it is too late to make such changes ('forces the user to specify whether the
> > transaction is write or read') - i have too many scripts to change.
>
> make every single sql execution follow this logic
>
> die 'nested lock' if global_recursion_flag
>
> global_recursion_flag = true
>
> ret = flock 'db.lock', LOCK_EX
> die 'lock failed' unless ret
>
> result = execute sql
>
> ret = flock 'db.lock', LOCK_UN
> die 'unlock failed' unless ret
>
> global_recursion_flag = false
>
> if all access is through this one class you CANNOT experience a locked
> database using this logic. if you are then:
>
> 0) some other process is locking the database
>
> 1) there is some database access NOT though this class
>
> 2) your app is doing some weird thread things fcntl based locks are process
> based so all thread 'get the lock'
>
>
> > About NFS i asked the hosting and they said they dont use NFS.
>
> good.
>
> > And can the lack of threadsafe lead to such behaviour? (i suppose it can...)
>
> i don't know - but seriously doubt it unless you're access is multithreaded.
>
> is it?
>
> > I must say also that the database seems to get locked during a select query
> > because i can read normally from the database but can't write in it.
>
> then some other process holds the lock.
>
> > i can't get the database to lock (exept when the script times out and i only
> > noticed that on a linux machine and i can't confirm that it also applies to
> > the server - probably will test that tommorow but even if it applies i have
> > put one hour timeout and my scripts are not that heavy i have 2 places if i
> > recall correctly where i use recursion and for the first i am 100% sure it
> > is ok and the second has been used for -4-5 months without problems and i
> > haven't changed anything on it)
>
> this smells fishy. obviously SOMETHING changed right? recursion and locking
> sounds like a great thing NOT to do! another thing you might try removing
> your
> database - seriously, if you coordinated ALL access through something like
>
> ret = flock 'db.lock', LOCK_EX
>
> mv '.db', 'db'
>
> result = execute sql
>
> mv 'db', '.db'
>
> ret = flock 'db.lock', LOCK_UN
>
> i would expect that the offending code (the secret locker you cannot determine
> with lsof or fuser) would begin to blow up. does that make sense? what i am
> saying is that if database never exists unless the lock is held then code that
> is not respecting the lockfile will fail because the database will not be
> there
> (tiny race condition i realize but this would certainly make offending code
> fail).
>
> > Can a query get the database locked? because i can't imagine a query that
> > can do that...
>
> i don't think so.
>
> > And what can lock a database?
>
> probably nothing but your own code ;-(
>
> > I tried not to commit a transaction but the database didn't lock... any
> > ideas?
>
> something is very, very wrong then:
>
> harp:~ > rm db; sqlite db 'create table foo(bar)'
>
> harp:~ > strace sqlite db 'begin;end;' 2>&1 | grep -i lck
> fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff7b30) = 0
> fcntl64(3, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff7b40) = 0
> fcntl64(4, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff7b30) = 0
> fcntl64(4, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff7b40) = 0
> fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff76b0) = 0
> fcntl64(3, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff7710) = 0
> fcntl64(4, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff76b0) = 0
> fcntl64(4, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff7710) = 0
> fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff76f0) = 0
> fcntl64(3, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff76c0) = 0
> fcntl64(4, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff76f0) = 0
> fcntl64(4, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff76c0) = 0
>
> harp:~ > strace sqlite db 'begin; insert into foo values(42); end;' 2>&1 |
> grep -i lck
> fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9ed0) = 0
> fcntl64(3, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9ee0) = 0
> fcntl64(4, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9ed0) = 0
> fcntl64(4, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9ee0) = 0
> fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9a50) = 0
> fcntl64(3, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9ab0) = 0
> fcntl64(4, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9a50) = 0
> fcntl64(4, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9ab0) = 0
> fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9a90) = 0
> fcntl64(3, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9a60) = 0
> fcntl64(4, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9a90) = 0
> fcntl64(4, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0},
> 0xbfff9a60) = 0
>
>
>
> -a
> --
> ===============================================================================
> | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
> | PHONE :: 303.497.6469
> | When you do something, you should burn yourself completely, like a good
> | bonfire, leaving no trace of yourself. --Shunryu Suzuki
> ===============================================================================
>
