Hi Emmanuel and Marc, Thank you for the answers...
Yes, you're right. I tested and looks like MySQL doesn't protect the operation only with commit. So I looked at the TPCW implementation (from Wisconsin) closely and found out that they protect the operation using "synchronized" keyword and this is why two tomcat servers won't work since you cannot synchronize the operations across machines (or processes). In order to make TPCW work with multiple application servers, I guess I need to change the implementation like the way Emmanuel suggested I tested again using one tomcat server and two MySQL backends and looks working fine but I get a lot of warning messages, though. What are those warnings about and how I can remove those warnings? 15:51:10,066 WARN backend.DatabaseBackend.tareka09 Unable to find table $tmp_bs1301 in database schema, when getting next entry to execute : DROP TABLE $tmp_bs1301/ 15:51:10,067 WARN backend.DatabaseBackend.tareka08 Unable to find table $tmp_bs1301 in database schema, when getting next entry to execute : DROP TABLE $tmp_bs1301/ 15:51:10,067 WARN backend.DatabaseBackend.tareka08 Unable to find table $tmp_bs1301 in database schema, when checking priority inversion for query DROP TABLE $tmp_bs1301/ 15:51:10,067 WARN backend.DatabaseBackend.tareka09 Unable to find table $tmp_bs1301 in database schema, when getting next entry to execute : DROP TABLE $tmp_bs1301/ 15:51:10,067 WARN backend.DatabaseBackend.tareka09 Unable to find table $tmp_bs1301 in database schema, when checking priority inversion for query DROP TABLE $tmp_bs1301/ 15:51:10,437 WARN backend.DatabaseBackend.tareka08 Unable to find table $tmp_bs1302 in database schema, scheduling query DROP TABLE $tmp_bs1302/ in conflicting queue. 15:51:10,437 WARN backend.DatabaseBackend.tareka09 Unable to find table $tmp_bs1302 in database schema, scheduling query DROP TABLE $tmp_bs1302/ in conflicting queue. Thanks, Jin On 11/10/06, Marc Herbert <[EMAIL PROTECTED]> wrote:
Marc Herbert <[EMAIL PROTECTED]> writes: >>> So before inserting a new record, it reads the max id >>> value in the table and increases it by one for the new id. After >>> insertion opertaion, TPCW commits transaction. MySQL server works >>> correctly with the operation. > You need a full SERIALIZABLE isolation level for this to be > thread-safe since a predicate read is involved. I just tested this manually with MySQL/InnoDB 5.0.24, using two concurrent "select max(id)" transactions, and it's not thread-safe. Both transactions happily insert the same n+1 value in the table. So it seems this InnoDB version does not really implement a "serializable" level. Could you please do the same manual test with your install? Thanks in advance. _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
-- Jin Heo Ph.D. Candidate Computer Science University of Illinois at Urbana-Champaign e-mail: [EMAIL PROTECTED] http://www.cs.uiuc.edu/homes/jinheo _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
