Hi Thomas, I dug further into this problem and found that the root cause is the use of the global constraints map in the org.h2.schema.Schema class to manage local temporary table constraints. It looks like a similar issue was addressed recently for indexes, but not for constraints.
It is legal to use the same name for a local temporary table across different sessions, but this results in Schema.getUniqueName() internally generating the same sequence of candidate names for a constraint on such tables. At this time, concurrent access to the constraints and temporaryUniqueNames collections is not threadsafe. As a result, a non-unique name can be returned by this method. I am working on a patch which will store constraints for local temporary tables in the Session object, similar to what is done with indexes. This way, all access to the map is done within a single Session only. Also, concurrent access to the shared temporaryUniqueNames set will have to be synchronized. Please let me know if you have any concerns with this approach. Thanks, Eric Faulhaber --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/h2-database?hl=en -~----------~----~----~----~------~----~------~--~---
