locking

Just to be sure that I correctly understand how things work. If I do em.lock(employee, LockModeType.PESSIMISTIC_WRITE); - will it block only this entity ( employee ) or the whole table Employees ? If it matters, I am talking about PostgreSQL . Anton Malyshev It should block only the entity. PostgreSQL hibernate dialect adds for update in case of write locks: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/PostgreSQL81Dialect.java#L549 (newer versions just use the same implementation) for update is treated row-wise by PostgreSQL: https:/

I'm doing a bash script that interacts with a MySQL datatabase using the mysql command line programme. I want to use table locks in my SQL. Can I do this? mysql -e "LOCK TABLES mytable" # do some bash stuff mysql -u "UNLOCK TABLES" The reason I ask, is because table locks are only kept for the session, so wouldn't the lock be released as soon as that mysql programme finishes? [EDIT] nos had the basic idea -- only run "mysql" once, and the solution nos provided should work, but it left the FIFO on disk. nos was also correct that I screwed up: a simple " echo X >FIFO " will close the FIFO; I

According to the Java Persistent/Locking wikibooks *, the best way to deal with locks is to report the Optimistic Lock Error/Exception to the user. The problem is that it's not scalable. Suppose that I have many users who are likely to cause a lock with the same action. The user does not care about the lock error message. In a nutshell : The best way is to disable all locks ? The best way is to report to the user the error lock message ? But the user must retry his action until it will work ! The best way is to retry the transaction until there's no lock ? * Handling optimistic lock exceptions

I have many web service call (asychronous), in callback, I will plot result to Excel. I want to synchronize the plot method. So I use the following, however, from I track down in Visual Studio, every time, lock(locker) is successful, and there are many threads running clearcommentIfany, plot. I can't figure out why this is not working as expected! Thanks private readonly object locker = new object(); void ProcessPlot() { lock (locker) { Debug.WriteLine("currentThreadID: " + Thread.CurrentThread.ManagedThreadId); //Helper.Dispatcher.Invoke(new AddClearCommentDelegate(ClearCommentIfAny));

I've got a table where I need to auto-assign an ID 99% of the time (the other 1% rules out using an identity column it seems). So I've got a stored procedure to get next ID along the following lines: select @nextid = lastid+1 from last_auto_id check next available id in the table... update last_auto_id set lastid = @nextid Where the check has to check if users have manually used the IDs and find the next unused ID. It works fine when I call it serially, returning 1, 2, 3 ... What I need to do is provide some locking where multiple processes call this at the same time. Ideally, I just need it

I'm currently running the following statement select * into adhoc..san_savedi from dps_san..savedi_record It's taking a painfully long time and I'd like to see how far along it is so I ran this: select count(*) from adhoc..san_savedi with (nolock) That didn't return anything in a timely manner so for the heck of it I did this: select top 1 * from adhoc..san_savedi with (nolock) Even that seems to run indefinitely. I could understand if there are millions of records that the count(*) could take a long time, but I don't understand why selecting the top 1 record wouldn't come back pretty much

I'm developing a mechanism for interchanging data between two or more processes using shared memory on linux. The problem is some level of concurrency control is required to maintain data integrity on the shared memory itself, and as I'm specting that sometime or another my process could be killed/crash, common lock mechanisms dont' work because they could left the memory in a "locked" state and right after dying, making other processes hung waiting for the lock to be released. So, doing some research I've found that System V semaphores have a flag called SEM_UNDO wich can revert the lock