No, I don't think so. This is a (J)BPM application where each user has their own tasks etc., so concurrent modifications of the same data should be very rare. In any case, with only a couple of users (~20) using the application, as there were at the time we tested, it would be impossible to get that many concurrent modification errors in such a short time. And more importantly, we were getting these errors with objects that are modified very rarely or even never at all. Really, one type of these objects is never ever modified after being created, so how could it be "concurrently modified"???
Regarding those pessimistic locking errors: they seem to be suppressed in the way that they don't cause any malfunctioning, but why are they logged as ERROR? JBossCache 1.2.4 at least logged just the error alone, without the stack trace, but 1.3 logs the entire stack, which is really inappropriate for expected behaviour. Can this be switched off somehow? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3946298#3946298 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3946298 ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
