Hi,
I think we are talking across each other here. I'm having Postgres-R in
mind, while I'm not sure what kind of clustering solution you are
talking about.
Tatsuo Ishii wrote:
> I'm not sure if I understand the concept of CO at all, but for me it
> seems sometimes transaction control which does not use CO is
> usefull.
Well, it depends a bit on what they mean by commit ordering. For
Postgres-R, an atomic broadcast protocol takes care of "ordering"
commits. I guess that counts as a commit ordering protocol.
> For example, we could send SELECT queries to each DB odes
> without any consideration of CO.
SELECTs are mostly read-only, so I don't quite understand what those
have to do with the order of commits.
> This will achieve higher concurrent
> processing with a price of occasional "global dealock", still this
> will be better solution in mostly-readonly-transaction environment.
Please elaborate on what kind of replication solution you have in mind
and how that generates global deadlocks.
In Postgres-R, only writing transactions need to be replicated. So only
their commits need ordering. All possibly global deadlocks will turn
into local deadlocks, so I'm only concerned with consistent resolution
of multiple local deadlocks.
I'd appreciate to hear your needs. Very possibly, there still is a huge
amount of overlap.
Regards
Markus Wanner
