Table refresh in synchronized block?

Hi to all,
my Vaadin App is accessed by 30 user concurrently which write data, read and other using Table and SqlContainer.

It runs on Tomcat 7.0.27 with JVM 1.6 u24 and sometimes, typically unders stress, the application server use lots of CPU and some Threads looks like to be in "BLOCKED" state.

This thread end its stackTrace with...

java.util.HashMap.getEntry ( HashMpa.java:347) 

I not use synchronized ( ... ) block in my app because I thought they can create problem, but in the forum I've read some discussions that say the countrary.

* What should I do in my multi-user app when I refresh data on Table with SqlContainer?
* Should or should not use synchronized blocks?
* What can cause this blocked thread?

P.S. Sometimes the blocked thread is the AbstractCommunicationManager at 747 line.

Thanks, Stefano

Additional info: in these table I use GeneratedColomn that get a Button with an Image; this Image is a static variable in a class that I use to load Image from my Theme.

Can this create problem?

------
Before crash, on catalina.out i see this

38099.658: [GC [PSYoungGen: 244800K->135680K(242752K)] 637831K->637535K(806720K), 1.2206180 secs] [Times: user=4.57 sys=0.25, real=1.22 secs]
38100.879: [Full GC [PSYoungGen: 135680K->73435K(242752K)] [PSOldGen: 501855K->563967K(853824K)] 637535K->637403K(1096576K) [PSPermGen: 47115K->47115K(55936K)], 2.5723170 secs] [Times: user=2.53 sys=0.04, real=2.57 secs]
38103.479: [GC [PSYoungGen: 107072K->106048K(308608K)] 671039K->670015K(1162432K), 0.4416910 secs] [Times: user=1.76 sys=0.00, real=0.44 secs]
38104.006: [GC [PSYoungGen: 213120K->106816K(322432K)] 777087K->777127K(1176256K), 0.6392680 secs] [Times: user=2.36 sys=0.15, real=0.65 secs]
38104.739: [GC [PSYoungGen: 225152K->118128K(323776K)] 895463K->895563K(1177600K), 1.4412780 secs] [Times: user=5.64 sys=0.06, real=1.44 secs]
38106.180: [Full GC [PSYoungGen: 118128K->18647K(323776K)] [PSOldGen: 777435K->853823K(1219136K)] 895563K->872471K(1542912K) [PSPermGen: 47115K->47043K(54912K)], 4.2059860 secs] [Times: user=4.15 sys=0.06, real=4.21 secs]
38110.464: [GC [PSYoungGen: 118336K->117104K(341632K)] 972159K->970927K(1560768K), 0.8948630 secs] [Times: user=3.55 sys=0.02, real=0.90 secs]
38111.464: [GC [PSYoungGen: 249008K->131552K(343808K)] 1102831K->1102788K(1562944K), 1.4222580 secs] [Times: user=5.57 sys=0.09, real=1.42 secs]
38112.992: [GC [PSYoungGen: 263456K->131944K(362176K)] 1234692K->1235052K(1581312K), 1.6976760 secs] [Times: user=6.58 sys=0.13, real=1.70 secs]
38114.689: [Full GC [PSYoungGen: 131944K->15761K(362176K)] [PSOldGen: 1103108K->1219135K(1398144K)] 1235052K->1234897K(1760320K) [PSPermGen: 47045K->47045K(54144K)], 4.8484810 secs] [Times: user=4.74 sys=0.11, real=4.85 secs]
38119.638: [GC [PSYoungGen: 144064K->140720K(366400K)] 1363199K->1359856K(1764544K), 1.1764430 secs] [Times: user=4.68 sys=0.01, real=1.18 secs]
38120.957: [GC [PSYoungGen: 284784K->136176K(386816K)] 1503920K->1496313K(1784960K), 1.6346310 secs] [Times: user=6.36 sys=0.12, real=1.63 secs]
38122.592: [Full GC [PSYoungGen: 136176K->98011K(386816K)] [PSOldGen: 1360136K->1398144K(1398144K)] 1496313K->1496155K(1784960K) [PSPermGen: 47045K->47045K(53120K)], 5.7714020 secs] [Times: user=5.74 sys=0.03, real=5.77 secs]
38128.412: [Full GC [PSYoungGen: 158656K->158656K(386816K)] [PSOldGen: 1398144K->1398144K(1398144K)] 1556800K->1556800K(1784960K) [PSPermGen: 47047K->47047K(52352K)], 5.8351020 secs] [Times: user=5.84 sys=0.00, real=5.84 secs]
38134.248: [Full GC [PSYoungGen: 158656K->154566K(386816K)] [PSOldGen: 1398144K->1398144K(1398144K)] 1556800K->1552710K(1784960K) [PSPermGen: 47047K->46840K(51328K)], 7.2197400 secs] [Times: user=7.21 sys=0.00, real=7.22 secs]
38141.470: [Full GC [PSYoungGen: 158656K->158656K(386816K)] [PSOldGen: 1398144K->1398144K(1398144K)] 1556800K->1556800K(1784960K) [PSPermGen: 46842K->46842K(50816K)], 5.8172720 secs] [Times: user=5.82 sys=0.00, real=5.82 secs]
38147.287: [Full GC [PSYoungGen: 158656K->157067K(386816K)] [PSOldGen: 1398144K->1398143K(1398144K)] 1556800K->1555211K(1784960K) [PSPermGen: 46842K->46841K(50304K)], 7.1711700 secs] [Times: user=7.17 sys=0.00, real=7.17 secs]
38154.466: [Full GC [PSYoungGen: 158656K->158656K(386816K)] [PSOldGen: 1398143K->1398143K(1398144K)] 1556799K->1556799K(1784960K) [PSPermGen: 46842K->46842K(49792K)], 5.8420700 secs] [Times: user=5.84 sys=0.00, real=5.84 secs]
38160.308: [Full GC [PSYoungGen: 158656K->157532K(386816K)] [PSOldGen: 1398143K->1398143K(1398144K)] 1556799K->1555676K(1784960K) [PSPermGen: 46842K->46840K(49280K)], 7.1503390 secs] [Times: user=7.15 sys=0.00, real=7.15 secs]

The crash was caused by a for (..) which never end.

But my question about synchronized block remains without answer. No-one know that?

Thanks, Stefano

Well 30 users in an application mean 30 separate threads - but they are all working on distinct objects and should not share any data (except you are doing some dirty things like using static). Synchronized-blocks are only necessary if data - or more precisly object-state - is shared across threads. This doesn't happen in a typical Vaadin-application, so you normally should not need to use synchronized.

For the shared data on your database you don't need to synchronize yourself, that must be done by the DBMS (configurable over Isolation-Levels).