HI Emmanuel,
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 ?Hi Andreas,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 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.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.
I will try to make a Jira Task. Thanks, Regards Andreas
Thanks for your feedback, EmmanuelHola 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 thislog4j.logger.org.continuent.sequoia.controller.recoverylog=DEBUG, Console,FiletraceBut i get 20:47:31,690 DEBUG sequoia.controller.recoverylog Logging request 120: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 0java.sql.SQLException: ORA-00911......What is the correct Trace setting in log4j to get see the insert statement, please.Thank you , Regards AndreasHi 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, EmmanuelThank 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 AndreasHi 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 ZeichenThe 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
