SCM Database corrupt after synch with ClearCase

The ClearCase synchronizer uses only the TeamConcert client library to
write to the server, so it is unlikely that it could create an invalid
checksum in the database. The use of TEXT_MODE=transparent only affects
the content that you write to the database, so I can't imagine that
causing a low-level problem like this.

I'll open a defect for the repository team, to see if they can give us
some guidance here.

Were you doing anything else with the database (upgrading it, whatever)
around the time you saw the corruption, or were you only using it for
importing ClearCase data?

While we're waiting for advice from the repo team, one thing to try is
to create a second ClearCase workspace (on the same stream/branch as the
first one), and start adding the roots to that second workspace (start
by adding one at a time, and then synchronizing), to see if the problem
is in a particular project. In particular, I'd first add the first
project you added to the first CC Workspace (since that one should be
OK), and then add the last root you added (in case it was the last one
that had a problem).

Cheers,
Geoff

Lars,

One more question. I believe I shared with you a while back a script to
do database backups that involved stopping the server and database,
backing up and then restarting. Could the run of these two tasks be
overlapping with the backup pulling the database out from under the sync?

Steve

Lars,

It appears from your attachments that you are using a Derby database (I
see the derby JDBC driver in the stack trace), is that correct? Also,
how much SCM data are we talking about here?

Geoff,

From the stack trace, it appears the database connection is lost in the
middle of the sync (see my attachment). Could we just be trying to throw
too much data at Derby at once.

Steve


------------------------------------------------------------------------

Caused by: java.sql.SQLException: No current connection.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(null)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(null)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(null)
at org.apache.derby.impl.jdbc.Util.noCurrentConnection(null)
at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(null)
at org.apache.derby.impl.jdbc.EmbedConnection.clearWarnings(null)
at com.ibm.team.repository.service.internal.db.jdbcwrappers.ConnectionStatWrapper.clearWarnings(ConnectionStatWrapper.java:117)
at com.ibm.team.repository.service.internal.db.jdbcwrappers.errlog.ConnectionErrLogWrapper.clearWarnings(ConnectionErrLogWrapper.java:73)
at com.ibm.team.repository.service.internal.db.jdbcwrappers.ConnectionLeakWrapper.clearWarnings(ConnectionLeakWrapper.java:114)
at com.ibm.team.repository.service.internal.rdb.RepositoryDatabase$Transaction.startTransaction(RepositoryDatabase.java:426)
... 111 more
com.ibm.team.repository.common.TeamRepositoryException: Failed to prepare the txn mode
at com.ibm.team.repository.service.internal.rdb.RepositoryDatabase$Transaction.startTransaction(RepositoryDatabase.java:431)
at com.ibm.team.repository.service.internal.rdb.RepositoryDatabase.runTransaction(RepositoryDatabase.java:262)
at com.ibm.team.repository.service.internal.rdb.RepositoryDatabase.runInTransaction(RepositoryDatabase.java:218)
at com.ibm.team.repository.service.internal.TransactionService.runInTransaction(TransactionService.java:77)
at sun.reflect.GeneratedMethodAccessor77.invoke(null)

Hi,

You are right we are using a scheduled job to stop sever, backup and
start server again (much like the script you shared with us)

The process overlapping thing was one of my orignal thoughts, but I did
some calculations and it should not be the case.

Thy synch started around 16:00 and backup routine occurs 22:15
According to the last line in the Ant script it terminated after 239
minutes (~4 hours).

But I agree it seems to be a logical explanation. Should I try to set-up
the synch again (with backup stopped) and see if the problems still exists?

BR

Lars



Steve Wasleski skrev:


Lars,

One more question. I believe I shared with you a while back a script
to do database backups that involved stopping the server and database,
backing up and then restarting. Could the run of these two tasks be
overlapping with the backup pulling the database out from under the sync?

Steve

There are two interesting experiments:
- Try the sync again, against the current state of the repository.
- Restore the database to the last backup before you started the sync
that failed, and then try the sync again.

Cheers,
Geoff

Lars Ohln wrote:

Hi,

You are right we are using a scheduled job to stop sever, backup and
start server again (much like the script you shared with us)

The process overlapping thing was one of my orignal thoughts, but I
did some calculations and it should not be the case.

Thy synch started around 16:00 and backup routine occurs 22:15
According to the last line in the Ant script it terminated after 239
minutes (~4 hours).

But I agree it seems to be a logical explanation. Should I try to
set-up the synch again (with backup stopped) and see if the problems
still exists?

BR

Lars



Steve Wasleski skrev:


Lars,

One more question. I believe I shared with you a while back a script
to do database backups that involved stopping the server and
database, backing up and then restarting. Could the run of these two
tasks be overlapping with the backup pulling the database out from
under the sync?

Steve

Failed to prepare the txn
mode" (can't find any log files)