El Jue 08 Ene 2004 19:56, Paul DuBois escribió:
At 19:16 -0600 1/8/04, Alfredo Cole wrote:
Hi:
(...)
The code I use is:
select lock
Sorry. It's select get_lock...
get code
add one to code
write code
release lock
and select release_lock...
That looks like pseudo code
LAST_INSERT_ID() is connection specific, so it is safe from the
concurrency issue.
See http://www.mysql.com/doc/en/example-AUTO_INCREMENT.html
and http://www.mysql.com/doc/en/Getting_unique_ID.html for more.
Michael
Alfredo Cole wrote:
El Jue 08 Ene 2004 19:56, Paul DuBois escribió:
At 19:16
LAST_INSERT_ID() is connection specific, so it is safe from the
concurrency issue.
Note: safe may not apply if you're using connection pooling :-)
--
Hassan Schroeder - [EMAIL PROTECTED]
Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com
* Hassan Schroeder
LAST_INSERT_ID() is connection specific, so it is safe from the
concurrency issue.
Note: safe may not apply if you're using connection pooling :-)
In what situation is this unsafe? In general, you would not call
LAST_INSERT_ID() without first having done an INSERT in the
Roger Baklund wrote:
LAST_INSERT_ID() is connection specific, so it is safe from the
concurrency issue.
Note: safe may not apply if you're using connection pooling :-)
In what situation is this unsafe? In general, you would not call
LAST_INSERT_ID() without first having done an INSERT in the same
* Hassan Schroeder
In what situation is this unsafe? In general, you would not call
LAST_INSERT_ID() without first having done an INSERT in the
same session, and even with connection pooling you would usually
use the same connection for all statements related to a session.
What am I
... and of course the _point_ of connection pooling: one assumes that there
is overhead involved connecting to the server, thus you would avoid a lot of
connect/one-small-session/close and instead have fewer
connect/many-small-sessions/close. It is relatively fast to connect to
MySQL, making
Roger Baklund wrote:
Maybe I don't understand connection pooling, then. Isn't its purpose
to allow a client -- say, a webapp running in Tomcat -- to multiplex
requests for *multiple* end users over a single connection?
Almost... except for the 'single connection' part. It will maintain a pool
of
* Hassan Schroeder
[...]
OK, but the user here is the servlet container (Tomcat), *not*
the human end user.
That should not make a difference, as seen from the server a client is a
client.
As would temporary tables, which is why I stopped using them for
request-specific data :-)
Right...
Roger Baklund wrote:
OK, but the user here is the servlet container (Tomcat), *not*
the human end user.
That should not make a difference, as seen from the server a client is a
client.
Huh? OK, Tomcat is the client of the MySQL server; user or
client, same situation.
As would temporary tables,
* Hassan Schroeder
[...]
Not errors, just the same temp table being shared across end
user requests.
ok... If you did this:
- create temp table
- use temp table
- drop temp table
for each session, I would expect it to work. (atleast until a session
crashes before it drops the temp table.)
Roger Baklund wrote:
ok... If you did this:
- create temp table
- use temp table
- drop temp table
for each session, I would expect it to work. (atleast until a session
crashes before it drops the temp table.)
This is straying from the original question :-) but my understanding
of temp tables is
Hassan Schroeder said:
Roger Baklund wrote:
Maybe I don't understand connection pooling, then. Isn't its purpose
to allow a client -- say, a webapp running in Tomcat -- to multiplex
requests for *multiple* end users over a single connection?
Almost... except for the 'single connection' part.
* Hassan Schroeder
Roger Baklund wrote:
ok... If you did this:
- create temp table
- use temp table
- drop temp table
for each session, I would expect it to work. (atleast until a session
crashes before it drops the temp table.)
This is straying from the original question :-)
Roger Baklund wrote:
Ouch. Very special, imo... this means the connection is re-negotiated for
each statement? Sounds strange. Maybe the client connection is 'virtual' or
'by proxy', so that multiple users actually share the same connection at the
same time?
If you want to think of it that way,
* Hassan Schroeder
Roger Baklund wrote:
Ouch. Very special, imo... this means the connection is
re-negotiated for each statement? Sounds strange. Maybe the
client connection is 'virtual' or 'by proxy', so that multiple
users actually share the same connection at the same time?
If you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roger Baklund wrote:
[snip]
A connection pooling implementation without this isolation, where multiple
users can share the same database connection at the same time is either
broken or intended for a special purpose (some non-multi-statement
Hi:
I have an application that is used by around 40 users who need to access a
table, obtain a sequential code, and write it back. I'm using MyISAM tables,
and mysql 3.23 running under LM 9.0.
A couple of times during the day, the users get the same code, and that is
causing us many problems.
At 19:16 -0600 1/8/04, Alfredo Cole wrote:
Hi:
I have an application that is used by around 40 users who need to access a
table, obtain a sequential code, and write it back. I'm using MyISAM tables,
and mysql 3.23 running under LM 9.0.
A couple of times during the day, the users get the same
19 matches
Mail list logo
