Hi Andreas,
Usually we recommend to use a database that is local to the controller
for the recovery log and users often opt for a small Java database. So
it's true, I don't recall anyone using Oracle for the recovery log.
Could you try to just modify the default value of escapeProcessing in
org.continuent.sequoia.controller.recoverylog.events.LogEntry line 46
and recompile. I think that should solve your problem.
Thanks again for the feedback,
Emmanuel
HI Emmanuel,
Hi Andreas,
I have downloaded the source code for sequoia to see what is realy
done.
BTW. I'am using 2.101.10. In the prepared statement you sent me was
missing this:
try
{
pstmt.setEscapeProcessing(logEntry.getEscapeProcessing());
}
catch (Exception ignore)
{
}
And this one is the problem. I have tried with my Testprogram and if
this is set to false it fails and if its set to true everything
works fine.
This means for the commands like "begin", "commit" etc. sequoia set
this to false for the update statement itself to true.
You are right, actually 'begin' and 'commit' are not executed as SQL
but as JDBC calls. By default, escapeProcessing is set to true in
Sequoia and the only way to de-activate it is to call
setEscapeProcessing(false) on the statement in the client
application. There is no global setting to overwrite the behavior
(though you can recompile a driver and modify the escapeProcessing
variable initialization in org.continuent.sequoia.driver.Statement to
set it to false.
I don't know why you are not using the default (not calling
pstmt.setEscapeProcessing) but if there is no possibility to
configure this behaviour then this is a Bug in sequoia !?
The escapeProcessing value could probably be overridden on the
driver side with a new option setEscapeProcessing=false. If you are
interested in such option, please file a JIRA entry and I'll
implement it for Sequoia 4. Not sure if this will be backported to
Sequoia 2.10 though.
Emmanuel it is the other way around, means "the default is true", and
with true it is working, if its set to false like for commit it fails.
So i think until now, no one is using a Oracle Database with
Transactions (autocommit to false) for the Recovery, could this be
possible ?
I will try to make a Jira Task.
Thanks, Regards Andreas
Thanks for your feedback,
Emmanuel
Hola Emmanuel,
I haven't any idea, because the insertion of the update statement
itself works only begin und commit fails and they are using the
same insert or ?
I wrote a small testprogramm and it works, but e.g. if i put a ";"
at the end of the insert it fails with this error.
My main problem now is to activate the right traces to see the
insert statement.
If tried this
log4j.logger.org.continuent.sequoia.controller.recoverylog=DEBUG,
Console,Filetrace
But i get
20:47:31,690 DEBUG sequoia.controller.recoverylog Logging request 1
20:47:31,690 DEBUG sequoia.controller.recoverylog Releasing
recovery log connection: oracle.jdbc.driver.t4cconnect...@1977b9b
20:47:31,691 DEBUG sequoia.controller.recoverylog Logging in
recovery log connection
20:47:31,724 DEBUG sequoia.controller.recoverylog
oracle.jdbc.driver.t4cpreparedstatem...@e61a35
20:47:31,749 DEBUG sequoia.controller.recoverylog Releasing
recovery log connection: oracle.jdbc.driver.t4cconnect...@1e328e0
20:47:31,752 ERROR sequoia.controller.recoverylog Failed to log
begin for transaction 0
java.sql.SQLException: ORA-00911......
What is the correct Trace setting in log4j to get see the insert
statement, please.
Thank you , Regards Andreas
Hi Andreas,
The code that inserts commands in the recovery log is as follows:
pstmt = connection.prepareStatement("INSERT INTO "
+ logTableName + " VALUES(?,?,?,?,?,?,?,?,?,?)");
pstmt.setLong(RecoveryLog.COLUMN_INDEX_LOG_ID,
logEntry.getLogId());
pstmt.setString(RecoveryLog.COLUMN_INDEX_VLOGIN,
logEntry.getLogin());
pstmt.setString(RecoveryLog.COLUMN_INDEX_SQL,
logEntry.getQuery());
pstmt.setString(RecoveryLog.COLUMN_INDEX_SQL_PARAMS, logEntry
.getQueryParams());
pstmt.setString(RecoveryLog.COLUMN_INDEX_AUTO_CONN_TRAN,
logEntry
.getAutoConnTrans());
pstmt.setLong(RecoveryLog.COLUMN_INDEX_TRANSACTION_ID,
logEntry.getTid());
pstmt.setLong(RecoveryLog.COLUMN_INDEX_REQUEST_ID, logEntry
.getRequestId());
pstmt.setString(RecoveryLog.COLUMN_INDEX_EXEC_STATUS, logEntry
.getExecutionStatus());
pstmt.setLong(RecoveryLog.COLUMN_INDEX_EXEC_TIME, logEntry
.getExecutionTimeInMs());
pstmt.setLong(RecoveryLog.COLUMN_INDEX_UPDATE_COUNT, logEntry
.getUpdateCountResult());
You could try this code directly on your Oracle recovery log
database to see what happens.
You can trace the exact statements by enabling DEBUG on the
recoverylog logger.
Hope this helps,
Emmanuel
Thank you for your answer. I have tried something but it has
nothing to do with the ..BOLBs. Either with VARCHAR2 for the
recovery log Table it's not working. But now i know the Problem
(not the solution). It has nothing to do with my Client. It has
to do with Transactions.
Even if i try to use the sql client from Sequoia it doesn't work
when i do the following:
Type begin on prompt, then an update statement -> then it fails
with this 911 Error from oracle. As i have understood you try to
insert the transactions commands into the recovery table also ?
As i don't see this insert command (can i trace it ?), maybe
there is something wrong with the statement (Wrong type, not
escaped)?
Do i something wrong or maybe ist a Configuration Problem?
Thank you , Regards Andreas
Hi Andreas,
It's not a problem of PreparedStatement encoding because even a
simple string text like 'commit' fails:
2009-01-30 15:25:32,264 ERROR sequoia.controller.recoverylog
Logger thread was unable to log LogRequestEvent: Log entry: log
id6 (T) transactionId:1 requestId:0 vlogin:user status: E
sql:commit params:null because of java.sql.SQLException:
ORA-00911: Ungültiges Zeichen
The reason might be that you have a unicode character that does
not match the charset of oracle. You could try to use NCLOB
instead of CLOB in your recovery log definition. You might want
to check your Locale settings on the Sequoia and Oracle machine
to make sure they are compatible.
I was also looking at
http://www.oracle.com/technology/sample_code/tech/java/codesnippet/jdbc/clob10g/handlingclobsinoraclejdbc10g.html
and they suggest that one can use the newly introduced
|Connection| property|: SetBigStringTryClob. The driver might
have some additional options for handling properly String
conversions.
Keep me posted with your findings,
|
Emmanuel
------------------------------------------------------------------------
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
------------------------------------------------------------------------
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
------------------------------------------------------------------------
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
------------------------------------------------------------------------
_______________________________________________
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
