Connection seems to cache data

[chris]

I open MySQL Manager and connect to my database.

I then insert one record in to an InnoDB table in MySQL (4.0 and 4.1
alpha hosted on XP running mysqld --console).

I then retrieve the record successfully in MySQL Manager using the
existing connection. This indicates that commit is running
successfully, (I have seen this on the database trace too).

I then try to retrieve the record (through a small MySQL/TomCat
application). Sometimes it is retrieved successfully, and sometimes an
empty record set is returned.

If I reduce connection pooling (on the connection script (in
components.xcon f))to min 1 max 1 connections, the record is retrieved
successfully every time.

This seems to me to indicate that existing connections created for my
TomCat app are searching on an old (maybe cached?) version of the
database. However, when by chance I get the same connection I used to
insert the record, the record is retrieved successfully.

However, the record is retrieved more often than not even when there
are 10 connections pooled, although I understand that connections are
not round-robbined and some are used more commonly than others,
supporting my suspision.

This is the only insert that uses transactions in my app, and it works
fine with Oracle. All other inserts (not using transactions) work fine
on both database servers (and both MySQL 4.1.1-alpha and 4.0.16).

Thanks very much for any time spent on this and any recommendations
for further tests or fixes.

[chris]

up*********@hot mail.com (chris) wrote in message news:<c6******* *************** ***@posting.goo gle.com>...

I open MySQL Manager and connect to my database.

I then insert one record in to an InnoDB table in MySQL (4.0 and 4.1
alpha hosted on XP running mysqld --console).

I then retrieve the record successfully in MySQL Manager using the
existing connection. This indicates that commit is running
successfully, (I have seen this on the database trace too).

I then try to retrieve the record (through a small MySQL/TomCat
application). Sometimes it is retrieved successfully, and sometimes an
empty record set is returned.

If I reduce connection pooling (on the connection script (in
components.xcon f))to min 1 max 1 connections, the record is retrieved
successfully every time.

This seems to me to indicate that existing connections created for my
TomCat app are searching on an old (maybe cached?) version of the
database. However, when by chance I get the same connection I used to
insert the record, the record is retrieved successfully.

However, the record is retrieved more often than not even when there
are 10 connections pooled, although I understand that connections are
not round-robbined and some are used more commonly than others,
supporting my suspision.

This is the only insert that uses transactions in my app, and it works
fine with Oracle. All other inserts (not using transactions) work fine
on both database servers (and both MySQL 4.1.1-alpha and 4.0.16).

Thanks very much for any time spent on this and any recommendations
for further tests or fixes.

The Workaround, further indicating that this is indeed a bug in MySQL.

I installed MySQL server 3.23.53, enabled InnoDB tables in my.cnf
(with the line innodb_data_fil e_path=ibdata:3 0M under the [mysqld]
section) and ran mysqld-max.exe and the problem seems to have
disappeared and transactions are working as they should. (But MySQL <
4.1.1 doesn't do subqueries etc...)

I have sent a bug report to MySQL.

Thanks again for any time anyone has spent on this. I am still
confused that I cannot find any sign of this defect anywhere on the
net.

[chris]

up*********@hot mail.com (chris) wrote in message news:<c6******* *************** ***@posting.goo gle.com>...

I open MySQL Manager and connect to my database.

I then insert one record in to an InnoDB table in MySQL (4.0 and 4.1
alpha hosted on XP running mysqld --console).

I then retrieve the record successfully in MySQL Manager using the
existing connection. This indicates that commit is running
successfully, (I have seen this on the database trace too).

I then try to retrieve the record (through a small MySQL/TomCat
application). Sometimes it is retrieved successfully, and sometimes an
empty record set is returned.

If I reduce connection pooling (on the connection script (in
components.xcon f))to min 1 max 1 connections, the record is retrieved
successfully every time.

This seems to me to indicate that existing connections created for my
TomCat app are searching on an old (maybe cached?) version of the
database. However, when by chance I get the same connection I used to
insert the record, the record is retrieved successfully.

However, the record is retrieved more often than not even when there
are 10 connections pooled, although I understand that connections are
not round-robbined and some are used more commonly than others,
supporting my suspision.

This is the only insert that uses transactions in my app, and it works
fine with Oracle. All other inserts (not using transactions) work fine
on both database servers (and both MySQL 4.1.1-alpha and 4.0.16).

Thanks very much for any time spent on this and any recommendations
for further tests or fixes.

The Workaround, further indicating that this is indeed a bug in MySQL.

I installed MySQL server 3.23.53, enabled InnoDB tables in my.cnf
(with the line innodb_data_fil e_path=ibdata:3 0M under the [mysqld]
section) and ran mysqld-max.exe and the problem seems to have
disappeared and transactions are working as they should. (But MySQL <
4.1.1 doesn't do subqueries etc...)

I have sent a bug report to MySQL.

Thanks again for any time anyone has spent on this. I am still
confused that I cannot find any sign of this defect anywhere on the
net.

[chris]

up*********@hot mail.com (chris) wrote in message news:<c6******* *************** ****@posting.go ogle.com>...

up*********@hot mail.com (chris) wrote in message news:<c6******* *************** ***@posting.goo gle.com>...

I open MySQL Manager and connect to my database.

I then insert one record in to an InnoDB table in MySQL (4.0 and 4.1
alpha hosted on XP running mysqld --console).

I then retrieve the record successfully in MySQL Manager using the
existing connection. This indicates that commit is running
successfully, (I have seen this on the database trace too).

I then try to retrieve the record (through a small MySQL/TomCat
application). Sometimes it is retrieved successfully, and sometimes an
empty record set is returned.

If I reduce connection pooling (on the connection script (in
components.xcon f))to min 1 max 1 connections, the record is retrieved
successfully every time.

This seems to me to indicate that existing connections created for my
TomCat app are searching on an old (maybe cached?) version of the
database. However, when by chance I get the same connection I used to
insert the record, the record is retrieved successfully.

However, the record is retrieved more often than not even when there
are 10 connections pooled, although I understand that connections are
not round-robbined and some are used more commonly than others,
supporting my suspision.

This is the only insert that uses transactions in my app, and it works
fine with Oracle. All other inserts (not using transactions) work fine
on both database servers (and both MySQL 4.1.1-alpha and 4.0.16).

Thanks very much for any time spent on this and any recommendations
for further tests or fixes.

The Workaround, further indicating that this is indeed a bug in MySQL.

I installed MySQL server 3.23.53, enabled InnoDB tables in my.cnf
(with the line innodb_data_fil e_path=ibdata:3 0M under the [mysqld]
section) and ran mysqld-max.exe and the problem seems to have
disappeared and transactions are working as they should. (But MySQL <
4.1.1 doesn't do subqueries etc...)

I have sent a bug report to MySQL.

Thanks again for any time anyone has spent on this. I am still
confused that I cannot find any sign of this defect anywhere on the
net.

Thanks to some great support from MySQL, I can confirm that this is
not a bug. Their explanation is concise:

It is due to InnoDB being multiversioning and the default isolation
level is REPEATABLE_READ , so therefore each connection is working off
a snapshot of any particular table at a point-in-time when that
connection's transaction started. If you already have a transaction in
progress on another connection, and you want to 'see' the results of a
subsequent transaction on a different connection, you have to make
sure you have a new 'snapshot' of the data, by calling 'commit' before
trying to reference the data. See:

http://www.innodb.com/ibman.php#Exam...onsistent_read

My guess is your application on Oracle is running in an isolation
level
of 'READ_COMMITTED ' (which is their default, I believe)[this is all
correct]. If your application ran in an isolation level of
'REPEATABLE_REA D', I would
venture to say you would see similar behavior.

I inserted a commit before the SELECT statement in question, and that
solved the problem. I removed it and added the line:

transaction-isolation = READ-UNCOMMITTED

...to the [mysqld] section of my C:\my.cnf file and that also fixed the
problem.

[chris]

up*********@hot mail.com (chris) wrote in message news:<c6******* *************** ****@posting.go ogle.com>...

up*********@hot mail.com (chris) wrote in message news:<c6******* *************** ***@posting.goo gle.com>...

I open MySQL Manager and connect to my database.

I then insert one record in to an InnoDB table in MySQL (4.0 and 4.1
alpha hosted on XP running mysqld --console).

I then retrieve the record successfully in MySQL Manager using the
existing connection. This indicates that commit is running
successfully, (I have seen this on the database trace too).

I then try to retrieve the record (through a small MySQL/TomCat
application). Sometimes it is retrieved successfully, and sometimes an
empty record set is returned.

If I reduce connection pooling (on the connection script (in
components.xcon f))to min 1 max 1 connections, the record is retrieved
successfully every time.

This seems to me to indicate that existing connections created for my
TomCat app are searching on an old (maybe cached?) version of the
database. However, when by chance I get the same connection I used to
insert the record, the record is retrieved successfully.

However, the record is retrieved more often than not even when there
are 10 connections pooled, although I understand that connections are
not round-robbined and some are used more commonly than others,
supporting my suspision.

This is the only insert that uses transactions in my app, and it works
fine with Oracle. All other inserts (not using transactions) work fine
on both database servers (and both MySQL 4.1.1-alpha and 4.0.16).

Thanks very much for any time spent on this and any recommendations
for further tests or fixes.

The Workaround, further indicating that this is indeed a bug in MySQL.

I installed MySQL server 3.23.53, enabled InnoDB tables in my.cnf
(with the line innodb_data_fil e_path=ibdata:3 0M under the [mysqld]
section) and ran mysqld-max.exe and the problem seems to have
disappeared and transactions are working as they should. (But MySQL <
4.1.1 doesn't do subqueries etc...)

I have sent a bug report to MySQL.

Thanks again for any time anyone has spent on this. I am still
confused that I cannot find any sign of this defect anywhere on the
net.

Thanks to some great support from MySQL, I can confirm that this is
not a bug. Their explanation is concise:

It is due to InnoDB being multiversioning and the default isolation
level is REPEATABLE_READ , so therefore each connection is working off
a snapshot of any particular table at a point-in-time when that
connection's transaction started. If you already have a transaction in
progress on another connection, and you want to 'see' the results of a
subsequent transaction on a different connection, you have to make
sure you have a new 'snapshot' of the data, by calling 'commit' before
trying to reference the data. See:

http://www.innodb.com/ibman.php#Exam...onsistent_read

My guess is your application on Oracle is running in an isolation
level
of 'READ_COMMITTED ' (which is their default, I believe)[this is all
correct]. If your application ran in an isolation level of
'REPEATABLE_REA D', I would
venture to say you would see similar behavior.

I inserted a commit before the SELECT statement in question, and that
solved the problem. I removed it and added the line:

transaction-isolation = READ-UNCOMMITTED

...to the [mysqld] section of my C:\my.cnf file and that also fixed the
problem.