Posted by Peter Veentjer around lunchtime: February 12th, 2008
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.
Posted by Peter Veentjer in the early evening: January 22nd, 2008
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…)
Posted by Peter Veentjer around lunchtime: November 28th, 2007
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…)
Posted by Peter Veentjer at around evening time: July 18th, 2007
Service layers are one of the most important parts of an enterprise system in my opinion, for a lot of reasons:
- defines what your system can and can’t do
- a good location for transaction demarcation
- a good location for security
And although a lot has been written about the service layer (Patterns of Enterprise Applications from Martin Fowler is one of the most famous books about this subject), there are a lot of ways to implement it. In this post I’ll walk through a few examples that are improved step by step.
(more…)
Posted by Peter Veentjer around lunchtime: March 1st, 2007
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.
Visibility problems
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.