Comments on: Concurrency issues in Hibernate statistics

By: Alex

Alex — Sun, 17 May 2009 02:56:25 +0000

@Dimitris: Ah, fair enough point. You might only be sampling the values without clearing them. A gui or whatever is monitoring the values could be diffing the ever increasing values.

By: Dimitris

Dimitris — Fri, 15 May 2009 07:29:09 +0000

(Also, I didn’t mean that they read the values only once per hour, but they would want to reset the statistics at that frequency, but anyway, doesn’t really matter).

By: Dimitris

Dimitris — Fri, 15 May 2009 07:27:41 +0000

Hi again,
I see my post truncated. Its end was “how would you do it better in Java 1.4″

By: Steve Ebersole

Steve Ebersole — Thu, 14 May 2009 13:19:40 +0000

Totally agree with everything you say. Its really a question of whether we want to spend time/effort ‘fixing’ this since, as you mention, we are stuck supporting JDK 1.4 for a bit longer yet or waiting till we can drop JDK 1.4 support and use its improved concurrency capabilities. An option here might be use of Doug Lea’s “oswego” concurrency package; there were a few other places where things like better concurrent collections would have been nice-to-have.

By: Alex

Alex — Thu, 14 May 2009 13:15:25 +0000

@Dimitris: In my experience, people are reading these values a lot more frequently than once an hour. But in general, yes (3) may be less severe.

In 1.5+, there are a bunch of options. You could use AtomicLong to safely read/write the stat values – that gives you visiblity and atomic increment. For the maps, a ConcurrentHashMap would probably be a good choice.