Strange behavior on pick load

Question

We have a strange behavior with TopLink when the load of the server increases : random errors appear in database : pimary key voilated !
After analysis, we noted that TopLink generates a SQL INSERT in the place of SQL UPDATE. We use the method registerObject for enregister the existing object in the unitOfWork but in certain cases Toplink does not see any more that the object exists and decides to insert it.
When we pass by again the same cases of figure after the peaks of loads, the program proceeds normally and TopLink generates SQL UPDATE.
Thank you for your assistance, our production suffers from this problem

Answer 1

Hello,
Looks like you have the existence checking set to checkcache only and are likely using a WeakIdentityMap for your objects identity. Under load, this could potentially cause references in the cache to be garbage collected, so that subsequent existence checks won't find them.
If the above is correct, you can increase/decrease the likelyhood of the problem occuring on a test system by tuning the JVM - removing/adding memory, tuning gc options etc. You might also want to tune each descriptor cache based on your applications usage as described at:
http://www.oracle.com/technology/products/ias/toplink/doc/10131/main/_html/cachun.htm#CHEJAEBH
In addition to setting JVM options that suit your application's usage and load, you can prevent the problem entirely by:
1) reading existing objects through the UOW instead of registering them. This will ensure that if the object has been removed from the cache, it will be read from the database. If it hasn't been removed, it is just a cache hit. Or
2) use the Check Cache then Database option.
Benifits of 1 are that if you know the object is new, you don't need to go to the database, but you can always use the RegisterNewObject api as well to avoid the database hit with option 2 anyway. There are probably more ways to avoid the problem, these are just the first two I thought of.
Best Regards,
Chris