locking

I have an application where I have a shared resource (a Motion system) which can be accessed by multiple clients. I have individual Operations that require access to the system for the duration of the move and which should throw 'Busy' exceptions if conflicting operations are requested at the same time. I also have Sequencers which need to acquire exclusive access to the Motion system for the execution of several Operations, interspersed with other actions; during the entire sequence, no other clients should be able to run Operations. I've traditionally approached this using Thread-affinity,

I have been reading thoroughly the postgres documentation on transaction isolation suggested in other of my questions but I have not still managed to understand the "predicate locking" stuff. I hope somebody can enlighten me :-) According to the documentation: Predicate locks in PostgreSQL, like in most other database systems, are based on data actually accessed by a transaction That sounds good, then why is the following happening? CREATE TABLE mycustomer(cid integer PRIMARY KEY, licenses integer); CREATE TABLE mydevice(id integer PRIMARY KEY, cid integer REFERENCES mycustomer (cid), status

What is the exact difference between the two locking read clauses: SELECT ... FOR UPDATE and SELECT ... LOCK IN SHARE MODE And why would you need to use one over the other? I have been trying to understand the difference between the two. I'll document what I have found in hopes it'll be useful to the next person. Both LOCK IN SHARE MODE and FOR UPDATE ensure no other transaction can update the rows that are selected. The difference between the two is in how they treat locks while reading data. LOCK IN SHARE MODE does not prevent another transaction from reading the same row that was locked.

I am trying to understand a paper on concurrent B-tree, in which the author mentioned latch vs lock, and how latches do not need a "Lock Manager". I have been trying to figure out what are differences between those two for two days. Google resulting in: "locks assure logical consistency of data. They are implemented via a lock table, held for a long time (e.g. 2PL), and part of the deadlock detection mechanism. latches are like semaphores. They assure physical consistency of data and resources, which are not visible at the transactional level" However, I am still pretty confused. Can some one

I'm modelling a game where multiple players (threads) move at the same time. The information of where a player is located at the moment is stored twice: the player has a variable "hostField" that references to a field on the board and every field has an ArrayList storing the players that are currently located at this field. I'm not very happy with the fact that I have redundant information, but I found no way avoiding that without looping through a big dataset. However, when a player moves from one field to another, I'd like to make sure (1) the redundant information stays linked (2) nobody

InnoDB Record, Gap, and Next-Key Locks http://dev.mysql.com/doc/refman/5.7/en/innodb-record-level-locks.html InnoDB has several types of record-level locks including record locks, gap locks, and next-key locks. For information about shared locks, exclusive locks, and intention locks, see Section 14.2.2.1, “InnoDB Lock Modes”. Record lock: This is a lock on an index record. Gap lock: This is a lock on a gap between index records, or a lock on the gap before the first or after the last index record. Next-key lock: This is a combination of a record lock on the index record and a gap lock on the

In a Java thread dump, you can see locks mentioned within stack traces. There seems to be three kinds of information: 1: - locked <0x00002aab329f7fa0> (a java.io.BufferedInputStream) 2: - waiting to lock <0x00002aaaf4ff6fa0> (a org.alfresco.repo.lock.LockServiceImpl) 3: - parking to wait for <0x00002aaafbf70bb8> (a java.util.concurrent.SynchronousQueue$TransferStack) 1: The thread has obtained a lock on object 0x00002aab329f7fa0. 2&3: Seem to say that the thread is waiting for the lock on said object to become available... but what is the difference 2 and 3? You will get "waiting to lock" in

ZooKeeper is a highly available coordination service for data centers. It originated in the Hadoop project. One can implement locking, fail over, leader election, group membership and other coordination issues on top of it. Are there any alternatives to ZooKeeper? (free software of course) I've looked extensively at Zookeeper/ Curator , Eureka , etcd , and consul. Zookeeper/Curator and Eureka are in many ways the most polished and easiest to integrate if you are in the Java world. Etcd is pretty cool and very flexible, but It is really just a HA key store so you would have to write a lot of