[pgpool-general: 2850] Problems with the LOCK patch in Bind phase included in 3.3.2

[Jose Maria Alvarez Fernandez]

Hi all,

I am writing because I would need some help with a strange behaviour we are
having with our pgpool2 installation.

Our deployment includes two Postgresql 9.3.4 servers in synchronous
streaming replication, and a pgpool2 cluster with watchdog configured to
access them, in replication mode and with load balancing.

When we deployed the 3.3.2 versión, we saw an unexpected behaviour that
wasn't there in the 3.3.1 release. Our application started to get deadlocks
when introducing data from different threads simultaneously. I think I've
narrowed the problem to this bugfix introduced in 3.3.2:

Fix data inconsistency problem with native replication mode + extended
      protocol case

Per bug report by Steve Kuekes in [pgpool-general: 2142].
      http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002171.html

It seems that, as our application is using OpenJPA to manage data, and
it doesn't ensure the insert order, some of the inserts trying to get
a lock in a table that other thread as already locked, but this thread
is also trying to acquire a lock in a table that the other thread has
already locked, due to the unordered insert statements.

Does anyone have an idea of how can we workaround this, to keep pgpool2
versions up to date? I haven't found an option to force OpenJPA to "order"
the inserts.

Thank you all,

Jose Maria.

-- 


Brightstar 20:20 mobile
C/ Arroyo de los Prados. 5. P.I. Las Arenas. 28320 (MADRID) Spain

------------------------------

This e-mail has been sent by Brightstar 20:20 mobile.

Telephone number: +34 911 032 160.

Please see our website for further information, www.brightstar-2020.es/<http://www.2020mobile.com/confidentiality-notice/>

*P please consider the environment and only print this if required*

------------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20140519/cbec0cfc/attachment.html>