one database config used by two jira Edited

[Quan QA]

perhaps opposite to one jira - two databases I read, which commented by @Nic Brough [Adaptavist] 

my question :

one database serving two jira instances would cause disaster ? dbconfig.xml will be same on the database connection, I think, so wonder is it possible I run jira 1 on one machine to access database 1,  then I install jira 2, still point out to database 1 ?  what would be happening ?

kind of reminding one servant two masters, but not at the same time :-D

any thoughts?  

Due to limited source, I only get one database for testing, so I wonder 'recycling' , however, should I contact DBA to wrap out whole database before I config it in another jira ? 

[Nic Brough [Adaptavist]]

For older versions of Jira, yes, it was a disaster.  Both of them would be unable to write issues correctly and their indexes fail rapidly.  If you left them long enough, with active users, you'd get a completely corrupt database.

Newer versions of Jira try to prevent the corruption - the first one to connect writes a record into a table which tells other installations that the database is in use, so they just shut down with an error saying the database is already in use by a previous Jira.

[Quan QA]

Thank you so much, @Nic Brough [Adaptavist].

my situation is to use SQL2014 for testing, but many times if possible, therefore, each new jira application launch, I just give same database config, that should be okay for jira software v7.6.0 without any extra work from DBA ? 

[Nic Brough [Adaptavist]]

No, you'll need to drop all the tables on each new run.  But you can use the same database over and over.

[Quan QA]

Thank you, @Nic Brough [Adaptavist],  our DBA gave me a database for testing, if I want to drop all the tables , what should I tell him?  can I run the query to get rid of tables on my given jiradbuser at all ?

[Quan QA]

no worries, I did something to let all tables 'gone', then recycle the database , so no bothering our DBA. 

not sure that's the final solution, but only for testing, on production, we would not change that much. :-)