[pgpool-general: 3909] Re: Unexpected error occurred in rollback
Yugo Nagata
nagata at sraoss.co.jp
Tue Aug 4 10:48:13 JST 2015
Hi,
I'll look into this. However, I'm not familiar with JPA and glassfish.
I would appreciate if you would send me some codes to reproduce the problem.
And, could you please send the log messages of both pgpool and postgresql?
On Sun, 2 Aug 2015 16:32:07 +0000 (UTC)
Videanu Adrian <videanuadrian at yahoo.com> wrote:
>
>
> Hi All,
> I have a pgpool-II version 3.3.4 (tokakiboshi) Master-Slave setup and two Postgres 9.3.3 servers configured also as Master-Slave with Streaming Replication.On a application side i have a JPA(Hibernate) app running on a glassfish 4.1 server.
> My nodes are defined as:
> backend_hostname0 = '192.168.1.31'
> backend_port0 = 5432
> backend_weight0 = 1
> backend_data_directory0 = '/var/lib/postgresql/9.3/data'
> backend_flag0= 'ALLOW_TO_FAILOVER'
>
> backend_hostname1 = '192.168.1.32'
> backend_port1 = 5432
> backend_weight1 = 0
> backend_data_directory1 = '/var/lib/postgresql/9.3/data'
> backend_flag1= 'ALLOW_TO_FAILOVER'
>
>
> on each postgresql node I have :
>
> # - Memory -
> shared_buffers = 2560MB # min 128kB
>
> max_prepared_transactions = 512 # zero disables the feature
> # (change requires restart)
> # Note: Increasing max_prepared_transactions costs ~600 bytes of shared memory
> # per transaction slot, plus lock space (see max_locks_per_transaction).
> # It is not advisable to set max_prepared_transactions nonzero unless you
> # actively intend to use prepared transactions.
>
>
> The problem is that when Node 1 (192.168.1.32) is the master (Node0 1.31 slave, after a failover) if something happens with a transaction and need to be rolledback I get :
>
> JTS5068: Unexpected error occurred in rollback
> org.postgresql.xa.PGXAException: Error rolling back prepared transaction
> at org.postgresql.xa.PGXAConnection.rollback(PGXAConnection.java:420)
> at com.sun.gjc.spi.XAResourceImpl.rollback(XAResourceImpl.java:195)
> at com.sun.jts.jta.TransactionState._rollback(TransactionState.java:212)
> at com.sun.jts.jta.TransactionState.rollback(TransactionState.java:180)
> at com.sun.jts.jtsxa.OTSResourceImpl.rollback(OTSResourceImpl.java:333)
> at com.sun.jts.CosTransactions.RegisteredResources.distributeRollback(RegisteredResources.java:1040)
> at com.sun.jts.CosTransactions.TopCoordinator.rollback(TopCoordinator.java:2291)
> at com.sun.jts.CosTransactions.CoordinatorTerm.rollback(CoordinatorTerm.java:530)
> at com.sun.jts.CosTransactions.TerminatorImpl.rollback(TerminatorImpl.java:286)
> at com.sun.jts.CosTransactions.CurrentImpl.rollback(CurrentImpl.java:767)
> at com.sun.jts.jta.TransactionManagerImpl.rollback(TransactionManagerImpl.java:372)
> ...............................................................................................
>
> And glassfish server needs to be restarted to kill all connections and open new ones.
> But, when Node 0 is the master this issue is not present. I have check and postgresql conf seems to be identical, at least in what concerns XA transactions...
> Any idea what could be the issue here ?
> Regards,
> Adrian Videanu
>
--
Yugo Nagata <nagata at sraoss.co.jp>
More information about the pgpool-general
mailing list