Hi Arnaud,
The Hibernate PostgreSQL dialects used to rely on Postgres sequences.
The problem is that sequences where updated using 'select nextval()'
which is interpreted as a select statement by Sequoia and therefore does
not get properly propagated and generates inconsistencies. This might be
the cause of your problem.
If you Google for it, you will probably find the page that details what
needs to be done to update the Hibernate dialect to replace the 'select
nextval()' with a '{call nextval()}'. This will work but will be
inefficient.
A better solution is to update the regular expressions catching the
select statements to be broadcast. I am planning to integrate that in
Sequoia 4 but did not have time to complete that yet.
Hope this helps,
Emmanuel
Hello Emmanuel,
In fact this a J2ee application which uses hibernate as ORM to
abstract from database. I use a jboss datasource behind a spring
connection factory. It's pool of 80 connections at maximum.
My scenario is about sending insert requests in a simple table.
Here is my recovery log section :
<RequestManager beginTimeout="10" commitTimeout="15"
rollbackTimeout="15">
<RequestScheduler>
<RAIDb-1Scheduler level="passThrough"/>
</RequestScheduler>
<LoadBalancer>
<RAIDb-1>
<WaitForCompletion policy="first"/>
<RAIDb-1-LeastPendingRequestsFirst/>
</RAIDb-1>
</LoadBalancer>
<RecoveryLog driver="org.hsqldb.jdbcDriver"
url="jdbc:hsqldb:hsql//192.168.0.35/xxx" login="sa" password="" >
<RecoveryLogTable tableName="RECOVERY" logIdColumnType="BIGINT
NOT NULL"
vloginColumnType="VARCHAR NOT NULL" sqlColumnType="VARCHAR
NOT NULL"
extraStatementDefinition=",PRIMARY KEY (log_id)"/>
<CheckpointTable tableName="CHECKPOINT"
checkpointNameColumnType="VARCHAR NOT NULL"/>
<BackendTable tableName="BACKEND"
databaseNameColumnType="VARCHAR NOT NULL"
backendNameColumnType="VARCHAR NOT NULL"
checkpointNameColumnType="VARCHAR NOT NULL"/>
<DumpTable tableName="DUMP" dumpNameColumnType="VARCHAR NOT NULL"
dumpDateColumnType="TIMESTAMP"
dumpPathColumnType="VARCHAR NOT NULL"
dumpFormatColumnType="VARCHAR NOT NULL"
checkpointNameColumnType="VARCHAR NOT NULL"
backendNameColumnType="VARCHAR NOT NULL"
tablesColumnType="VARCHAR NOT NULL"/>
</RecoveryLog>
</RequestManager>
I'm using sequences, but not for this test. This table uses uuid
generated from hibernate.
Any idea ?
Thank you.
Regards,
Arnaud GIULIANI.
Emmanuel Cecchet a écrit :
Hi Arnaud,
Hello and sorry for my unprecised questions,
the fact is that controllers are not stable under load (around 50
request by seconds on 2 controllers). If I slow down the load to 20
request by seconds, it becames reasonnable and activity came back
after 15 min, when I disable and enable a backend (logs are register
all the time).
What do you mean by unstable?
Are the 50 req/s just writes? Is it single threaded or do you have
multiple connections in parallel?
Are you using connection pooling in your applications?
Do you use transactions?
Do you use stored procedures?
What is the average query response time?
How large are the ResultSets if you have any reads?
My main problem is now about the log engine. Even with a load of 20
request by seconds, I have some problems :
My scenario
- 2 controllers with each a postgresql database and RAIDb1 management
- load under 20 request by seconds
- after 2 min of activity (around 2000 rows), my databases are
consistent
- I disable one backend to do a backup => it takes 5 min to disable,
but everything is ok
Are you using persistent connections?
Do you have long running transactions?
The 5 minutes seems very long.
- I make my dump
- Enable the backend ... unstable : logs can't often be replayed. If
it failed, I must restore log other node. And even there, I can't
restore anything. My second node stay disabled.
There is certainly something wrong, either in your recovery log
definition (column definitions might be inaccurate and truncate
information) or Sequoia misinterpret some the SQL you are using.
Are you using sequences, triggers, user-defined functions or stored
procedures? Anything that would be mentioned as not supported in the
Sequoia doc?
The error for log replay is an sql error, saying that there's
already the data or duplicate id (sequence).
Any ideas ?
Sequences are not supported by Sequoia unless you take necessary
precautions. How are you accessing the sequences in your requests?
Thanks for your feedback,
Emmanuel
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [email protected]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
