Simon Wittber wrote:
I considered doing exactly the same thing a while ago, but was worried
about running into an annoyance like that.
FWIW, The synchronous Pyro server performed much faster than the
multithreaded version, even under heavy use from 3 machines.
It appeared that while the database queries were serialized, network
IO was not. I infered this from the observation that a large result
set would take around 15 seconds to complete, yet other smaller
queries were able to run about 2-3 seconds after the large query was
started.
Sw.
This is standard "real DB" behavior. The transactions must appear to
have been executed in _some_ serial order, not the order of arrival.
If the small ops are simply retrieving data, they may return data
from "before" the transaction of of the larger, slower transaction.
Even if they mutate the DB, they may be inserted early if the larger
transaction has not in fact "read" the data they will right. Also,
in some cases, the smaller ones may be allowed to proceed and force
the larger one to abort if it attempts to acquire locks on the data
they write.
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
