First of all, forget about synchronized methods. A so-called synchronized method… synchronized AnyType foobar(…) { doSomething(); } Is nothing but a shortcut way of writing this: AnyType foobar(…) { synchronized(this) { doSomething(); } } There is nothing special about the method in either case. What is special is the synchronized block, and what a synchronized … Read more
Oracle has had an excellent multi version control system in place since very long(at least since oracle 8.0) Following should help. User A starts a transaction and is updating 1000 rows with some value At Time T1 User B reads the same 1000 rows at time T2. User A updates row 543 with value Y … Read more
This occurs when two Sql Server processes are accessing the same resources, but in a different order. Therefore they end up both waiting for the other process, which is a deadlock. There are a number of ways to prevent it, including: Avoid taking unneccessary locks. Review the transaction isolation level required for the query, use … Read more
Some quick tips out of my head don’t use multiple threads (like Swing does, for example, by mandating that everything is done in the EDT) don’t hold several locks at once. If you do, always acquire the locks in the same order don’t execute foreign code while holding a lock use interruptible locks
You can create a deadlock by using the steps shown below. First, create the global temp tables with sample data. –Two global temp tables with sample data for demo purposes. CREATE TABLE ##Employees ( EmpId INT IDENTITY, EmpName VARCHAR(16), Phone VARCHAR(16) ) GO INSERT INTO ##Employees (EmpName, Phone) VALUES (‘Martha’, ‘800-555-1212’), (‘Jimmy’, ‘619-555-8080’) GO CREATE … Read more
Wait-Die scheme It is a non-preemptive technique for deadlock prevention. When transaction Tn requests a data item currently held by Tk, Tn is allowed to wait only if it has a timestamp smaller than that of Tk (That is Tn is older than Tk), otherwise Tn is killed (“die”). In this scheme, if a transaction … Read more
readLock.lock(); This means that if any other thread is writing (i.e. holds a write lock) then stop here until no other thread is writing. Once the lock is granted no other thread will be allowed to write (i.e. take a write lock) until the lock is released. writeLock.lock(); This means that if any other thread … Read more
For the same thread a lock is always reentrant, so the thread can lock an object as often as it wants.
If a thread already holds a lock, then it can “take that lock” again without issue. As to why that is, (and why it’s a good idea), consider the following situation, where we have a defined lock ordering elsewhere in the program of a -> b: void f() { lock(a) { /* do stuff inside … Read more
Well, based on the definition of: A deadlock is a situation wherein two or more competing actions are each waiting for the other to finish. I would say that the answer is no – sure a thread can sit there waiting indefinitely for something, however unless two competing actions are waiting for each other it … Read more