It would get confused, because there is no way that the two JTS's could determine which data belongs to them. The schema is not made for this use case. To avoid users shooting themselves into the foot, for instance during an upgrade like the one to 3.x, the applications lock their DB and detect if multiple apps try to access it. hence the error.

For testing purposes I was able to run two Jazz RTC Servers sharing the same single oracle database repository.

As is configuration is not documented, I'd like to know if there have been any tests done, that this setup is working stable and consistant?

I suspect RTC would get very confused. To be clear, you want to run both RTC apps connecting to the same database tables?

anthony

p.s There is working on clustering going on - and we can already run two RTC instances with one as a standby.

From my tests with trying to connect 2 separate JTS's on different machines to the same DB server, using the same logical Jazz DBs, this was not possible, and received the following message:

CRJAZ1770E The configured database lock id does not match the lock id in the database.
This can happen if 2 applications or Jazz Team Servers are trying to access the same set of
tables, or if the lock id was overwritten or lost in the teamserver.properties configuration file.
Check the server configuration and the database connection spec and ensure they are correct.
To recover from an emergency lockout, the lock can be reset using the 'repotools -resetRepoLockId'
command. Check the log file for information on the affected database.

When one JTS setup was finished, it placed a lock on the DBs, therefore disallowing me to connect my second JTS to the same DBs. I was unsuccessful in using the repotools command above to remove the lock to complete the setup of my second JTS.

The reason for this test was to try setup a 'manual' DR or Idle Standby strategy. Anyone have any reference material of DR,High Availability or Idle Standby using Tomcat?