Bugs item #542808, was opened at 2002-04-11 22:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542808&group_id=31885
Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Layne Weathers (layne_weathers)
Assigned to: Nobody/Anonymous (nobody)
Summary: nextid()'s lock() in db_mysql.inc
Initial Comment:
nextid() issues a table lock on the db_sequence table -
this will release any previous locks. I do not
believe that nextid() is competent to make that
decision on its own. In most applications, I lock
tables before modifying any data, do integrity and
validity tests on the new data, and finally make the
changes. Since I don't like throwing away auto-
incrementing ID #s, I don't call nextid() until right
before the insert statement. Unfortunately, nextid()
will release my other locks and compromise my efforts
at data integrity.
If my methodology above is flawed I am willing to
change it, but until persuaded otherwise I propose the
following order for nextid():
1. check to see if an instance-level lock is in place
1.1. if not, try to put a lock on the sequence table
1.1.1. if successful, record that a local lock
was used
1.1.2. if unsuccessful, fail with current warning
2. get current id, increment it, write it to table
(unmodified)
3. check for a local lock
3.1 if so, release it
(Yes, this will cause problems in existing code where
nextid() is used within a set of locked tables and the
sequence table was not locked - the author was sloppy
and overlooked the sequence table, s/he should fix the
code.)
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542808&group_id=31885
|
