Re: Global Deadlock Information

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