Browse Prior Art Database

An efficient way to resolve locking scenario in any RDBMS systems Disclosure Number: IPCOM000248866D
Publication Date: 2017-Jan-19
Document File: 2 page(s) / 38K

Publishing Venue

The Prior Art Database


The disclosed method is an efficient way to resolve locking scenario in any RDBMS systems. In any relational database mananagement systems (RDBMS), the queries are becoming so complex that they lock more than one objects in the database and can make other queries wait for locked objects forever. We are suggesting a mechanism by which the more important queries need to wait for small amount of time before less important application releases locks. This will help to prioritise workload internally without end user's intervention. The application deverlops will have a control over queries and related objects. Search Keywords: Databases, Locks, Locktimeout, LockRelease.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.


An efficient way to resolve locking scenario in any RDBMS systemsIn any RDBMS (Relational Database Management System), a lock is used when multiple users need to access a database concurrently. This prevents data from being corrupted or invalidated when multiple users try to read while others write to the database. Any single user can only modify those database records to which they have applied a lock that gives them exclusive access to the record until the lock is released. Locking not only provides exclusivity to writes but also prevents (or controls) reading of unfinished modifications (i.e. uncommitted data).With current RDBMS design, there is a provision of specifying locktimeout value. It specifies the number of seconds that an application will wait to obtain a lock, helping avoid global deadlocks for applications. For eg. if locktimeout is set to 30 seconds, the application waiting on some lock can wait for maximum 30 seconds. Later it rolls back itself.The problem here is that the application waiting on lock is getting rolled back all the time. There is no provision to rollback the transaction holding the lock. Let's say we have 2 transactions running on system - TranA and TranB. TranA is low important transaction as compared to TranB. Now when TranA is holding some lock and if TranB is waiting on same lock, the TranB will be rolled back in 30 seconds though TranB is more important transaction.The solution we are proposing here is new parameter such as LOCKRELEASETIME. The user can configure it in terms of number of seconds and needs to be defined at connection level. For eg:database connect to TESTDBdatabase set current LOCKRELEASETIME 20W...