[ 
https://forge.continuent.org/jira/browse/SEQUOIA-539?page=comments#action_13611 
] 

Guillaume Smet commented on SEQUOIA-539:
----------------------------------------

I have finally found what was the problem for us. The application (Red Hat WAF) 
uses a sequence with cache. It's a not so well known feature of PostgreSQL 
which allows to affect a certain amount of sequence values in memory. It can 
probably be useful sometimes but IMHO it's a very bad idea to use it.

Summary of the problem:
- Backend 1 active, backend 2 disabled, sequence with a cache of 1000
- in connection 1, nextval returns 1 and sets the the sequence to 1000. Values 
from 2 to 1000 are kept in memory for the following nextval calls of _this_ 
connection
- in connection 2, nextval returns 1001 and sets the the sequence to 2000. 
Values from 1002 to 2000 are kept in memory for the following nextval calls of 
_this_ connection
- let's enable the backend 2, the recovery log is run in one and only one 
connection so the sequence will be set to only 1000 because the first nextval 
will return 1 and the second one will return 2 from the in memory cache of the 
PostgreSQL backend of this connection.

Perhaps we should add a note in the documentation (there is a specific 
paragraph about sequences and PostgreSQL IIRC) about this behaviour. Sequoia 
can't be used when using sequences with cache (which is not recommended anyway).

I modified the database schema of the application to fix the problem.

> Postgres Sequences
> ------------------
>
>          Key: SEQUOIA-539
>          URL: https://forge.continuent.org/jira/browse/SEQUOIA-539
>      Project: Sequoia
>         Type: Bug
>   Components: Recovery Log
>     Versions: Sequoia 2.8.1
>  Environment: 2 Windows XP running Postgres, One XP machine running Sun 
> Application Server 8.1 (J2EE Application that uses Hibernate) that 
> communicates with controller running on the same machine.  Controller is 
> configured with one cluster which interact with the 2 Postgres databases.  
> HSQL database stores recovery log.
>     Reporter: Lee Cooper
>     Assignee: Emmanuel Cecchet
>      Fix For: Sequoia 2.9
>  Attachments: information.zip
>
>
> I am new to sequoia but I believe I have found a bug with the version I am 
> running  2.8.1 BUILD 10.  I am investigating the use of sequoia in a BT 
> project.
> I have been testing Sequoia Recovery:
> When I run both backends everything works well all data and sequences are 
> duplicated across both databases (RAIDb-1 approach).
> However in the follwing senario I dicoover a problem with recovery.
> disable backend1
> (ADD NEW ROW USING HIBERNATE WHICH USES MY SequoiaDialect which overloads the 
> sequence method on the PostgresDialect)
> enable backend1
> The recovery seems to work well on the surface but when you dig deeper the 
> sequence value on backend1 (relating to that new added row) does not change 
> (increment)
> This later causes obvious problems when sequence is gained from backend1 and 
> then violates the PK constaint on backend1 and backend2.
> I have followed the documentation to the letter in regards to postgres and 
> hibernate and am very confident that I have configured the Controller 
> correctly.
> I will be happy to provide all xml config if required.
> I am very keen to use the product and when I have more experience with it I 
> hope to contribute to its further development.
> Lee

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://forge.continuent.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to