Bug 4226 – Problem with multiple instances of RFT accessing the same database

Bug 4226 - Problem with multiple instances of RFT accessing the same database

Summary:

Problem with multiple instances of RFT accessing the same database

Status:	ASSIGNED

Product:	RFT
Component:	RFT
Version:	development
Platform:	All All

Importance:	P3 enhancement
Target Milestone:	4.2
Assigned To:	Ravi Madduri

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2006-02-17 13:01 by Patrick Duda
Modified:	2006-10-03 10:41 (History)

Attachments
Patch for fixing multiple instances of RFT accessing the same database (6.24 KB, patch) 2006-02-17 13:05, Patrick Duda	Details
Changes to add a unique container ID to each request. (10.96 KB, patch) 2006-03-15 14:15, Patrick Duda	Details
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Patrick Duda 2006-02-17 13:01:37

When multiple instances of RFT attempt to use the same database, duplicate key
errors arise.  Tables are used to hold counters that act as primary keys for RFT
transfers.  The methods, getNextTransferId and getNextRequestId which are in
ReliableFileTransferDbAdapter.java, read, increment and update these tables. 
When multiple instances access the same database, these methods become a
critical section.

The patch being submitted takes advantage of databases inherent locking
mechanisms.  Transaction management and table locking have been added to the
methods in question.  By doing this, the instance that reads from the table
holds an exclusive lock on the table until it is done updating. 

The file rft_schema_mysql.sql has also been modified.  By default, MySQL creates
tables using an engine that does not allow for transactions and table locking in
the traditional sense.  The tables� requestid and transferid need to be created
with the InnoDB engine, which allows for traditional locking and transactions.

This patch has been tested with both PostgreSQL and MySQL.  It appears that the
current use of Derby will not allow for the above technique.  The Derby server
is being started in embedded mode and this mode allows only a single instance to
connect.

------- Comment #1 From Patrick Duda 2006-02-17 13:05:23 -------

Created an attachment (id=853) [details]
Patch for fixing multiple instances of RFT accessing the same database

------- Comment #2 From Ravi Madduri 2006-02-20 11:56:00 -------

Patrick
thanks for the patch. I will have to take a look how this breaks support for
derby since we are moving towards having RFT use derby by default. I will try
and isolate the code so that it won't break when derby is used

------- Comment #3 From Ravi Madduri 2006-02-20 13:36:53 -------

Patrick
are you trying to have more than one RFT service access/use a single database
instance? This is not supported with the present code base as the restart
information of a RFT request is stored in the database instance too. So the
services will be restarting each other instances. Right now, the one RFT
deployment should correspond to one database instance. The patch you provided
will probably address one change that needs to go in in order for multiple RFT
deployments to use a single db, but i think there are more places. We do have a
plan to add support for this in future by using container-id in the db schema to
make sure restarts work fine across multiple containers.

------- Comment #4 From Patrick Duda 2006-03-15 14:15:49 -------

Created an attachment (id=879) [details]
Changes to add a unique container ID to each request.

A new field needs to be added to the request table: containerID.  This field
will hold a unique identifier for each row based on the container that inserts
the row into the database.  This patch adds the code to insert the value and
also use the value in selecting correct rows on a restart.