Bug 724798 (BRMS-638)

Attachment: Added: server.log

Affects Testing: Added: [Blocks Testing]

It's strange that it works for some DBMSes but not others. Could this be due to the differences in transaction isolation level? That kind of makes sense that the database needs a bit more liberal isolation.

I'd suggest changing the isolation level for Oracle or MySQL, and trying again. If that works, then try it for the other two DBMSes.

Assigning to Kurt as he requested: "I would say the only way is to reproduce it in an integration test to reproduce, so that we can isolate and understand the issue, then if it turns out to be a ModeShape issue we can ask Randall for help. Please assign to me and i will take a look. It'd be great to have a debug trace of this as well."

Link: Added: This issue relates to BRMS-622

Link: Added: This issue relates to BRMS-646

Created attachment 514701 [details]
server.log with hibernate INFO

I've attached server log containing hibernate logging at INFO level. I find these entries interesting:

2011-07-22 15:23:48,478 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) Running hbm2ddl schema export
2011-07-22 15:23:48,479 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) exporting generated schema to database
2011-07-22 15:23:49,368 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) Unsuccessful: create table DNA_CHANGELOG (ID bigint not null auto_increment, CHANGES longblob not null, CHANGE_COUNT integer not null, UTC_TIMESTAMP bigint not null, USERNAME varchar(64) not null, primary key (ID)) ENGINE=InnoDB
2011-07-22 15:23:49,369 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UTC_TIMESTAMP bigint not null, USERNAME varchar(64) not null, primary key (ID)) ' at line 1
2011-07-22 15:23:50,358 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) Unsuccessful: create index NS_CHANGE_TS_INX on DNA_CHANGELOG (UTC_TIMESTAMP)
2011-07-22 15:23:50,358 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UTC_TIMESTAMP)' at line 1
2011-07-22 15:23:51,866 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) schema export complete

Created attachment 514706 [details]
modeshape-debug.log

Also attaching org.modeshape DEBUG output.

Jiri, just double checking that the Mysql5 dialect is being set in the hibernate config? --Kurt

The problem is in the use of UTC_TIMESTAMP as a column name.   The column name is being renamed.   Also, since this table is no longer used, it is being deprecated.

So it looks like this issue is caused by a modeshape column naming issue:
https://issues.jboss.org/browse/MODE-1225. I'm assuming the same is
true for the other databases this issue is reported on.

--Kurt

A fix for MODE-1225 has been committed into the '2.5.x' branch currently used for the 5.2 products, so it should appear in the next build.

I would pick up in the next build BRMS 5.2 ER2

FYI: BRMS depends on the ModeShape service, so it is a runtime dependency only; You don't have to wait for a new BRMS build to upgrade the ModeShape service.

ModeShape was rebased yesterday into git.app and a mead build was done.

The latest ModeShape build fixes MODE-1225 (failing schema export due to UTC_TIMESTAMP column), but we still get the exception during jboss-brms.war deployment. The exception can be view in the attached server.log.

I don't see the log file. With the fix, there is no longer a UTC_TIMESTAMP column, and in fact the table in which the column appears should no longer appear in the schema. As a result, I'm not convinced your using a ModeShape build containing the fix.

Sorry, I haven't probably made myself clear enough.

Firstly, we confirm that MODE-1225 is fixed in the latest ModeShape build, that Van is referring to in comment 16.

Secondly, we still encounter the exception contained in attachment 514566 [details]. That means the bug reported in this bugzilla is not directly caused by MODE-1225 and the real cause needs to be looked fore somewhere else (might not be a ModeShape bug at all). That's why I have already assigned back to Tihomir to conduct further investigation.

Created attachment 518041 [details]
server.log with a recent Modeshape (BRMS 5.2.0 ER2)

Attaching a recent server.log

Created attachment 518042 [details]
Modeshape configuration used

I should mention that server running on top of Oracle 11g was used to generate these past two attachments.

MODE-1225 has been resolved and should be in the next build.     This was an issue with Oracle and PostreSQL.

Jirka already explained the situation in comment 19 - we know that the issue is fixed *AND* repository initialization still fails with Modeshape. Please see attachment 518041 [details], which is the current manifestation of the problem.

If you wish, we can close this bug and file a new one for this new problem.

Commit ID:   24938f14255fdc2a037a
for MODE-1245 was committed to the 2.5.x branch to resolve the ItemNotFoundException that is occurring at start up time.    

This should be available for the next BRMS ER3 build.

This bug is now fixed. Thanks!