J(2)ee, the basics and beyond
Posted by Sander Hautvast at around evening time: June 30th, 2009
In this series I want to address some topics that are old and well known, but still seem to puzzle developers and administrators in a j2ee environment. Think of anything in or around an application server. When talking of application servers I mostly refer to websphere. Sadly I have no real experience using any other. Yet I aim to keep a broad perspective, not to narrow the audience. The level should be beginner to intermediate.
Part1 Starting your own threads.
As long as I worked with application servers, people have always told me not to start my own threads, because the j2ee specification states that this is forbidden. These threads are also referred to as 'naked' and 'unmanaged'. The danger they pose is doing things that the application server knows nothing about. It could cause resource leaks, no debugging, failing to stop a server or security problems.
Yet there is a number of open source frameworks that do just this, and no one seems to object. Think of quartz, or Log4j (the watchdog that monitors changes in log4j settings). And even the jdk itself is guilty: use of java.util.Timer also causes so called unmanaged threads.
Understanding Google Wave
Posted by Sonny Gill mid-morning: June 8th, 2009
(This blog post gives an overview of the architecture and technical concepts in Google Wave. If you are interested in how to use Google Wave in your applications, see Developing with Google Wave)
At Google I/O 2009, Google unveiled Wave. Wave is a new way of thinking about online conversations.
Consider the following situations -
- You write a blog post. Somebody comes around and posts a really insightful comment. Now, you or the comment author want to convert that comment into an independent blog post.
- You have been having a long email discussion with a colleague. Now you would like to invite another colleague to the same. She will need to know the context of the discussion and how it evolved.
- You email a few colleagues a draft of an article for review. They all email their comments back to you. A lot of them are suggesting the same changes without realizing that they have already been addressed.
With the tools we are using today such as email, blogs, IM etc., all of the above will require some kind of tedious copy - paste, and manual tracking of the changes being made.
Is there a better way?
The Google Wave model tries to provide a better way (more...)
Software Transactional Memory – Podcast – JSpring ‘09 Preview
Posted by Robert van Loghem around lunchtime: March 28th, 2009
On the 15th of April the NLJUG (Dutch Java User group) will be holding their J-Spring conference. Four Xebians will be presenting. Every week we'll be providing a sneak preview on the podcast of one of those presentations.
The first sneak peek is about Software Transactional Memory by Peter Veentjer.
You can find more information at the NLJUG presentation page.
Peter's presentation is from 11:20 to 12:10.
Hosted by Robert van Loghem.
This preview is in Dutch. After the 15th we'll be doing a full episode in english about STM.
So head on over to the show page or subscribe to our podcast!
JVM Threading optimizations revisited
Posted by Jeroen Borgers in the late evening: February 18th, 2009
By Jeroen Borgers
Last week I instructed an in-house performance tuning course and explained the participants about the threading optimizations in the Java 6 VM. We run the exercises of the course on Java 6 update 11 and when I told them that Escape Analysis did not work properly yet, I realized I did not really know this for a fact for this update of Sun’s Java. So, it is time to re-run the benchmark and find some unexpected results. (more...)
Concurrency and the evil intern
Posted by Erik Pragt mid-afternoon: March 12th, 2008
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!
EJCP: #9 Stopping threads
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.
EJCP Top 10: Nested monitor lockout
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...)
Oracle and ORA-08177
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...)
Spring and visibility problems
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.
Archives
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)