Hi there,Indeed! That was one thing I was thinking of, but the fact that InnoDB has non-saga style "transaction nesting" makes things a bit difficult.
Given this model, each thread is obviously going to want to have
multiple transactions outstanding. Is this something that might be added
to MySQL in future or am I totally overestimating the expense of using
one thread per connection?
I'm guessing you mean that each thread will want to have a number of
different transactions active at one time. Depending on how your
application works, you could nest transactions on one connection through
careful use of savepoints and rollbacks to save points (under InnoDb from
4.0.14). This won't help overlapping transactions that don't nest neatly
though.
Alternatively you can use connection pooling and have it such that you use aThat was also something I looked at, but was worried about hitting the limit of the connection pool.
connection per transaction. You could make it such that once all the
connections were taken, your application blocked the start of further
transactions.
Damned disks...err...I mean I was going to store all of my data in RAM anyway..... :-)I think you should be careful though. While a good design will help performance, you might end up finding that the benefits of your design are lost since disk IO or some other larger factor proves to be a much bigger bottleneck!
Thanks,Thanks for your insights!
Mike
Regards,
Chris
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
