Though concurrency is not really a hobby of mine, but I do find it interesting, and once in a while, it gets me intrigued. This article is about locking, and choosing the right type of lock and what the consequences are when picking the wrong lock!
Filed under: Concurrency Control, Java, Performance
3 Comments
Continuing the Enterprise Java Concurrency Problem Top 10 countdown, it's time to talk about number 9 'Stopping threads'.
Stopping a Thread is complicated. In the beginning the Thread.stop() method was added for this purpose, but is has been
deprecated for a long time. The reason is when some thread calls stop() on a victim thread, a ThreadDeath error is thrown inside the victim thread. And while this error propagates up the stacktrace, all locks the victim thread owns, are released. This means that the victim-thread could leave objects (on which it held locks) in an inconsistent state. So stopping a thread should be a cooperative mechanism between threads: the victim thread and the initiating thread both need to agree upon a protocol being used.
Filed under: Concurrency Control, Java
13 Comments
Concurrent programming is going to be even more important with the introduction of the multi-core cpu's. Running the complete application on a single cpu's (single threaded) is going to lead to less effective usage of hardware. Luckily in most cases, applications are inherently concurrent (like a standard request/response web-application) so a developer doesn't need to deal often with explicit concurrency control. But it doesn't mean that even such simple applications are free of concurrency problems. In this Enterprise Java Concurrency Problems (EJCP) Top 10, I'm going to list my 10 most important issues I look at, when I need to find concurrency problems within Enterprise Java applications. (more...)
Filed under: Concurrency Control, Java
2 Comments
When using Oracle, or other MVCC (Multi Version Concurrency Control) databases like Postgresql or MySql in combination with InnoDb, a transaction with the SERIALIZABLE isolation level doesn't always block (a pessimistic approach) when it conflicts with another transaction. Instead a more optimistic approach is used. This approach however can lead to an abort of the transaction with the feared: "ORA-08177: can't serialize access for this transaction", which in essence is just an optimistic locking failure. (more...)
Filed under: Concurrency Control, Oracle
2 Comments
Spring is a great framework, but I expect that some Spring based applications are subject to visibility problems (a type of concurrency problem). This blog entry describes the cause and effects of this problem, and also how it can be solved.
Most programmers don't have much experience with multi threading and have a very simplistic view on reality: if a thread makes a change to a variable, this change is directly visible to all other threads that access the same variable. This view is called sequential consistency, but the problem is that no virtual machine automatically provides this view.
Filed under: Concurrency Control, Java, Spring
2 Comments