470,848 Members | 1,708 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,848 developers. It's quick & easy.

concurrency, locks, multi-user app.

I'm investigating this subject, particularly DB interactions, and could
use input.
It seems the dominant consensus, in these discussions is "use flock()
...."
I guess this would be similar to, in Java terms, using synchronized
(objLock) { ... }

This lends itself to OOP modularization, localization of reads and
writes, using locks.

Also, MySQL might say in the manual,
this storage engine locks at the [page | row | ...] level.

But what does this get you ?
If the goal is consistent data, and no simultaneous writes, its a
worthy goal.
But how should the application be designed ?
Do you limit access to reports, displays, forms on data that is
currently being written ?
If a PHP flock() or DB lock impedes access, what then ?
Does it wait a time slice then try ? or throw error ? fatal error ?
recover ?

Any good articles, references ? any from Wrox, O'Reilly ? TIA for
responses

Jan 6 '06 #1
1 1636
awebguynow wrote:
I'm investigating this subject, particularly DB interactions, and could
use input.
It seems the dominant consensus, in these discussions is "use flock()
..."
I guess this would be similar to, in Java terms, using synchronized
(objLock) { ... }
True.

Problem with flock is however that W$-machines have no clue what you are
talking about. :-(

This lends itself to OOP modularization, localization of reads and
writes, using locks.

Also, MySQL might say in the manual,
this storage engine locks at the [page | row | ...] level.
Yes.

But what does this get you ?
If the goal is consistent data, and no simultaneous writes, its a
worthy goal.
It means that mySQL will manage this for you where and when appropriate.
You do not have to worry about the details yourself, unless you want to
optimize (you can give mySQL hints), or want to lock some tables/rows for
some other reason.

In general: Just trust your database engine to do its job right.
But how should the application be designed ?
Well...
How can we answer such a question?

Some shots in the dark:

If you are doing webstuff: Just include a connection-file above every script
that gives you a valid connection to the datatabase.
Use this connection in your script for select/update/delete/etc.

I am unsure if mySQL understands transactions.
If you want a better database, switch to Postgresql: it is a lot more
mature.
Do you limit access to reports, displays, forms on data that is
currently being written ?
Most database engines have a maximum number of connections, if that is what
you mean. Ofter 32 or 64. But that number can easily be modified by some
ini-file.
If a PHP flock() or DB lock impedes access, what then ?
flock and database row/table lock are two different things. They share the
word 'lock' but that is about it.
But for both goes that the script that trying it waits and tries again.
Maybe they use some fancy sheduling behing the scenes (like monitor
functionality found in Java), but I am unsure about the how and when.
Does it wait a time slice then try ? or throw error ? fatal error ?
recover ?
For flock: just try it yourself.
Make 1 script that flocks a file.
Make another that tries this too.

Any good articles, references ? any from Wrox, O'Reilly ? TIA for
responses


www.php.net is a good resource. Be sure to read all usercontributions too.
They help a lot understanding what is going on.

Hope this helped you a bit.

Regards,
Erwin Moller
Jan 6 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

31 posts views Thread by Derek Fountain | last post: by
7 posts views Thread by chessplayer | last post: by
1 post views Thread by Shawn B. | last post: by
2 posts views Thread by Jürgen Devlieghere | last post: by
9 posts views Thread by corey.coughlin | last post: by
9 posts views Thread by Anthony Paul | last post: by
2 posts views Thread by Pallav singh | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.