Emmanuel, On 12/27/06, Emmanuel Cecchet <[EMAIL PROTECTED]> wrote:
As Sequoia increases request latency, it is possible that it exhibits application level synchronization problems faster. These issues might not be seen under low load with when accessing directly the database.
Yep, I thought of that too a few days ago. The problem is that the persistence layer of RH WAF is very opaque and it's difficult to track anything in it. And as Sequoia is the complicated part of the connection handling, I thought it was more probably my problem. I finally found a way to track the connection and pid (using a PostgreSQL query) on the client side so I was able to see what happens. The fact is that for every query which returns a resultset the persistence layer takes a connection then releases it and takes another one from the pool for the next query/resultset and so on. There is no chance that the connection is the same than the previous one so in the case of a transaction, it's catastrophic. It's so obvious it can't work that I didn't think it was possible to code that sort of thing... I found a solution - not sure it's really perfect as I can't change the whole layer and there may still be a few cases when the connection is closed (network error or anything else) and instead of throwing an error, it takes another connection to commit - but anyway, it seems to work. I'll work on that a bit more. During my work, I found this thread from a PostgreSQL mailing list which may be of some interest for you as I don't think Sequoia acts like that currently: http://archives.postgresql.org/pgsql-jdbc/2006-09/msg00040.php Thanks for your feedback on my problem. It really helped me to search at the right place. -- Guillaume _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
