[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