I think you're missing the concept of a transaction in the database sense.
The idea behind a transaction is that you can perform multiple steps and if
you don't complete all steps, any changes are reversed. The reversal process
is handled by the database.
A good example is moving money from bank
On 6/5/07, Brent Baisley [EMAIL PROTECTED] wrote:
I think you're missing the concept of a transaction in the database sense.
The idea behind a transaction is that you can perform multiple steps and if
you don't complete all steps, any changes are reversed. The reversal process
is handled by the
David T. Ashley wrote:
There is no concept that I'm missing. I understand what a transaction is.
But I just don't want to bothered. My application is simple enough that
bogarting the database until all necessary modifications have been made and
the tables are again consistent is good enough.
On 6/5/07, Baron Schwartz [EMAIL PROTECTED] wrote:
David T. Ashley wrote:
There is no concept that I'm missing. I understand what a transaction
is.
But I just don't want to bothered. My application is simple enough that
bogarting the database until all necessary modifications have been
Hi David,
On Jun 5, 2007, at 3:55 PM, David T. Ashley wrote:
My only concern with GET_LOCK() is that lock is server-global
rather than
database-global. This makes attacks possible in a shared setting
(some bad
person could disable your database code by going after your lock).
My solution
David T. Ashley wrote:
I decided to go with a simple paradigm for my web-based database. Rather
than transactions, each process locks the entire database while it is
changing something, then unlocks it. This just serializes access (all
other
processes will block until the one modifying the
On 6/4/07, Gerald L. Clark [EMAIL PROTECTED] wrote:
David T. Ashley wrote:
LOCK TABLE thistable, thattable, theothertable,
goshthislistcangetlongtable;
Do whatever is needed;
UNLOCK TABLES;
You could use a string lock for this.
Thanks for the suggestion. It looks logically correct.
www.the-infoshop.com
www.giiexpress.com
www.etudes-marche.com
-Original Message-
From: David T. Ashley [mailto:[EMAIL PROTECTED]
Sent: Monday, June 04, 2007 3:54 PM
To: mysql@lists.mysql.com
Subject: Re: Lock Tables Question
On 6/4/07, Gerald L. Clark [EMAIL PROTECTED] wrote
On 6/4/07, Jerry Schwartz [EMAIL PROTECTED] wrote:
Whatever you do, make sure that every bit of code that locks multiple
resources locks them in the same order. That's the only way to avoid
deadlocks.
Hi Jerry,
I really appreciate the good advice.
However, my original question is still
David T. Ashley wrote:
On 6/4/07, Jerry Schwartz [EMAIL PROTECTED] wrote:
Whatever you do, make sure that every bit of code that locks multiple
resources locks them in the same order. That's the only way to avoid
deadlocks.
Hi Jerry,
I really appreciate the good advice.
However, my
Once you issue a LOCK TABLES command, you may not access any tables not
in the LOCK statement. You must lock *ALL* tables you will use, perform
your updates, and then UNLOCK TABLES.
I didn't know that. I reviewed the documentation. Thanks.
OK, then my only remaining question is how many
Hi
From the analysis of other sources,
The error may be due to:
1. MediaWiki was updated from an older version without updating the database.
so to update the database, you can use either the maintenance script
maintenance/update.php via the command line, or the web installer (rename
mysqldump --user root --password=password horsewiki horsewiki.sql
Dan Buettner wrote:
Hmmm, sounds like something's pretty abnormal here. Any idea what may
have been done here?
I wonder if you could step around this with a call to mysqldump that
doesn't explicitly lock tables ... what is
I tried this first to no avail.
mysqldump --user root --password=password --skip-lock-tables horsewiki
horsewiki.sql
mysqldump: mysqldump: Couldn't execute 'show create table `archive`':
Table 'horsewiki.archive' doesn't exist (1146)
I'll try the update next.
Visolve DB Team wrote:
Hi
Buettner
Cc: mysql@lists.mysql.com
Subject: Re: LOCK TABLES
I tried mv archive.frm .archive.frm first. Then I ran
mysqldump again.
It moves past archive and onto another table. I did this 6
times, each
time moving the next one it complained about until I stopped and put
them all back.
Dan
Incorporated
195 Farmington Ave.
Farmington, CT 06032
860.674.8796 / FAX: 860.674.8341
-Original Message-
From: mdpeters [mailto:[EMAIL PROTECTED]
Sent: Monday, October 16, 2006 9:19 PM
To: Dan Buettner
Cc: mysql@lists.mysql.com
Subject: Re: LOCK TABLES
I tried mv archive.frm .archive.frm
Michael, is the 'archive' table present in your database? e.g., if
you do a 'LIST TABLES', does it show up? What happens if you do a
SELECT * FROM archive LIMIT 1 ?
I'd hazard a guess that you may have a table definition file with no
actual table data files, if you're on MyISAM tables.
If you
As you can see, it is clearly showing up but I cannot do anything with it.
mysql show tables;
+-+
| Tables_in_horsewiki |
+-+
| archive |
| categorylinks |
| externallinks |
| hitcounter |
| horse_archive |
|
Try looking in the filesystem for the file(s) called archive in the
database directory, and move them somewhere else (or if you know you
don't need them, delete them).
If it is/was a MyISAM table, or just an errant file, this should work.
If it is/was InnoDB, this will be trickier ...
Dan
On
I tried mv archive.frm .archive.frm first. Then I ran mysqldump again.
It moves past archive and onto another table. I did this 6 times, each
time moving the next one it complained about until I stopped and put
them all back.
Dan Buettner wrote:
Try looking in the filesystem for the file(s)
Hmmm, sounds like something's pretty abnormal here. Any idea what may
have been done here?
I wonder if you could step around this with a call to mysqldump that
doesn't explicitly lock tables ... what is the commad you're running
again?
Dan
On 10/16/06, mdpeters [EMAIL PROTECTED] wrote:
I
Hello.
I think it is a weird behavior. I've reported a bug:
http://bugs.mysql.com/bug.php?id=9511
Bob O'Neill [EMAIL PROTECTED] wrote:
If I try to read table 'b' after locking table 'a', I expect to get
the error message Table 'b' was not locked with LOCK TABLES.
However,
You only need to lock whene you are going to run a query that contains
a series of actions and they all have to happen at the same time. As
for single queries, they are already atomic, so you don't need to put
and locks around them.
On Mon, 11 Oct 2004 11:14:36 +0100, Melanie Courtot [EMAIL
Version 4.0.15 comes after version 4.0.2 (15 2), so the version is not a
problem here.
From the manual: As of MySQL 4.0.2, to use LOCK TABLES you must have the
global LOCK TABLES privilege and a SELECT privilege for the involved
tables. http://dev.mysql.com/doc/mysql/en/LOCK_TABLES.html
The
Fernando Monteiro wrote:
Hello, Michael,
Version 4.0.15 comes after version 4.0.2 (15 2), so the version is
not a problem here.
(...)
I asked them to give me the lock tables permission, but they
answered this permission
option isn't available on versions prior to 4.0.2. They also told me
they
On 22-Jan-2004 Michael McTernan wrote:
Hi there,
Thanks for your quick response!
Why all the locks, temp tables and updates? You can just do:
SELECT
CASE WHEN B.y IS NULL THEN A.x ELSE B.y END AS newX
FROM
A LEFT JOIN B ON A.x = B.x
Spot on - many thanks! I wasn't aware of the
Michael McTernan said:
I'm using MySQL 4.0.15-standard-log, on RedHat 9.0 with InnoDb tables.
Essentially I have two tables, one table is a list of integers,
while the second is a table of integer pairs. e.g.
+---+ +-+-+
| A | | B.x | B.y |
+---+ +-+-+
| 1 | | 1
something now :)
Thanks,
Mike
-Original Message-
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]
Sent: 22 January 2004 16:38
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: LOCK TABLES and multi table UPDATE
Michael McTernan said:
I'm using MySQL 4.0.15-standard-log
On Thu, Sep 18, 2003 at 03:00:17PM +1000, [EMAIL PROTECTED] wrote:
Hi there i have a couple of projects which required fulltext searching so
was unable to setup innodb on these. I was wondering if lock tables is a
secure way to make the transaction on these tables and does this prevent
being
rollback works on myisam ? this is mysql4 anyway, sweet i'll give it a
try.
On Fri, 2003-09-19 at 08:01, Jeremy Zawodny wrote:
On Thu, Sep 18, 2003 at 03:00:17PM +1000, [EMAIL PROTECTED] wrote:
Hi there i have a couple of projects which required fulltext searching so
was unable to setup
- Dathan Vance Pattishall
- Sr. Programmer and mySQL DBA for FriendFinder Inc.
- http://friendfinder.com/go/p40688
---Original Message-
--From: electroteque [mailto:[EMAIL PROTECTED]
--Sent: Wednesday, September 17, 2003 6:38 PM
--To: [EMAIL PROTECTED]
--Subject: Re: Lock
At 11:38 AM +1000 9/18/03, electroteque wrote:
rollback works on myisam ? this is mysql4 anyway, sweet i'll give it a
try.
Rollback *doesn't* work with MyISAM, that's why Jeremy said you have
to put the necessary logic in your application if you want to achieve
the same effect.
At least, that's
would.
Matt
- Original Message -
From: electroteque
Sent: Wednesday, September 17, 2003 8:38 PM
Subject: Re: Lock tables in myisam
rollback works on myisam ? this is mysql4 anyway, sweet i'll give it a
try.
On Fri, 2003-09-19 at 08:01, Jeremy Zawodny wrote:
On Thu, Sep 18, 2003
No rollback does not work on myisam Jeremy was stating that you don't
have to do what you suggested to implement a correct ROLLBACK in mySQL.
Use INNODB.
http://www.mysql.com/doc/en/COMMIT.html
Hmm if you got my other post i am trying to simulate innodb in myisiam for
projects that
Righty, so if error unlock table hehe, i have found i need to produce my
error first then do a rollback for an error to display in php as it wouldnt
show a mysql error after a rollback, i guess i could add an unlock table in
my trigger error function too.
At 11:38 AM +1000 9/18/03, electroteque
On Thu, Sep 18, 2003 at 11:38:17AM +1000, electroteque wrote:
rollback works on myisam ? this is mysql4 anyway, sweet i'll give it a
try.
No. That's what I meant about having to put extra smarts in your code.
It needs to be able to undo its actions.
On Fri, 2003-09-19 at 08:01, Jeremy
Hi,
No, ROLLBACK doesn't work with MyISAM. Jeremy meant that you can add
logic/code between LOCK/UNLOCK to simulate ROLLBACK. e.g. queries
that undo what you did if something goes wrong. Of course this won't
cover you if mysqld dies, is killed, or you lose the connection etc. as
real
K.L. [EMAIL PROTECTED] wrote:
The 3.23.54 Manual states in;
Section 1.4.4.3 Transactions
If you only obtain a read lock (as opposed to a write lock), then reads and
inserts are still allowed to happen. The new inserted records will not be seen
by any of
So, when client X has Read lock, the client Y cannot have Write lock, Egor?
Iulian
- Original Message -
From: Egor Egorov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 1:33 PM
Subject: Re: Lock Tables - Manual Ambiguity
K.L. [EMAIL PROTECTED] wrote
: Egor Egorov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 1:33 PM
Subject: Re: Lock Tables - Manual Ambiguity
K.L. [EMAIL PROTECTED] wrote:
The 3.23.54 Manual states in;
Section 1.4.4.3 Transactions
If you only obtain
Subject: Re: LOCK TABLES error , on a select without any update ?
Heikki,
Please do NOT do any more research into this problem for the
time being. I was finally able to capture a log when the problem
occurred in production. In studying the log I discovered two things.
1) The new code to do
Steff,
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Heikki Tuuri [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, February 22, 2003 1:26 AM
Subject: Re: LOCK TABLES error , on a select without any update ?
Hi Heikki
]
Subject:Re: LOCK TABLES error , on a select
without any update ?
Date sent: Sat, 22 Feb 2003 10:52:08 +0200
Steff,
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Heikki Tuuri [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED
Steff,
We have our connection set to Autocommitt=1, and No table locks
are ever explicitly being done on this table anyplace in any of our
code modules.
in MySQL you have to do LOCK TABLES on EVERY table you use inside a LOCK
TABLES. You cannot lock just some table and use others unlocked.
I
Hi Heikki,
Thanks for picking up on this again. After the help from
you and Mark last week, we removed ALL instances of the
lock tables from our application. We used the idea Mark
provided for getting our next sequence number without using
any locks. In the past this was the only thing
I would investigate ways of writing that long running job so
that it does not require locking a table for long periods of time.
Use relative updates, break the procedure down into
smaller lockable steps with pauses for other programs etc.
Clyde wrote:
Hi,
As per a previous thread I have found
Gee, I hope there is no such thing as a timeout value for Lock Tables. :)
If two of my programs decide that one of them needs to wait for the other,
however long that may take, then I hope MySQL honors that chosen symbiosis.
I hope it behaves like a Perl flock(): it just waits, and waits, and
*** REPLY SEPARATOR ***
On 11/01/2003 at 1:29 PM Mark wrote:
Gee, I hope there is no such thing as a timeout value for Lock Tables.
:)
If two of my programs decide that one of them needs to wait for the other,
however long that may take, then I hope MySQL honors that chosen
At 17:12 +0800 1/11/03, Clyde wrote:
Hi,
I have searched the docs but can't seem to find information on the
time out value for Lock Tables (probably just me)
When using Lock Tables how long does MySql wait before giving up
if it can't get a lock?
Forever.
For table-level locks such as you
It is not a bug.
As soon as Computer1 releases the lock,
Computer2 will have its query processed.
Never write a program that keeps a lock for more than a few miliseconds.
Eric Cotting wrote:
MYSQL Server: 3.23.49a-log
MYSQL Client: 3.23.3 alpha
MYSQLGUI: 1.7.5
Operating System: Windows NT,
I'll try posting this again, because nobody has replied to it.
To put the problem more succinctly: I think there is a flaw in the mysql
LOCK statement semantics, because if I use LOCK then all tables that are
accessed while the LOCK is active must be locked for READ or WRITE
access (or insert,
Raju
-Original Message-
From: Bob Sidebotham [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 07, 2002 2:00 PM
To: [EMAIL PROTECTED]
Subject: Re: LOCK TABLES issue
I'll try posting this again, because nobody has replied to it.
To put the problem more succinctly: I think there is a flaw
52 matches
Mail list logo