Øystein Grøvlen wrote: >>>>>>"DJD" == Daniel John Debrunner <[EMAIL PROTECTED]> writes: > > > DJD> [As an aside traditionally Cloudscape did not use synchronized > *static* > DJD> methods as there were locking issues related to class loading - this > was > >> From jdk 1.1 days, have those issues been fixed now?] > > I am not an expert on this, but Doug Lea says in "Concurrent > Programming in Java": > > The JVM internally obtains and releases the locks for Class > objects during class loading and intialization. Unless you > are writing a special class ClassLoader or holding multiple > locks during static initialization sequences, these internal > mechanics cannot interfere with the use of ordinary methods > and blocks synchronized on Class objects.
Thanks. The "Unless ... holding multiple locks.. " part is a little troubling. And exactly what is meant by 'Class objects', as while you can have a synchronized static method, I don't see how you could have a block synchronized in the same way. The Derby code uses the workaround of creating a static final member referencing an object to be used as the synchronization object and uses that to synchronized static methods. That may still be the safest approach. E.g. public class X { private static final Object syncMe = new Object(); public void static someMethod() { synchronized (syncMe) { // ... code } } } > > I found an example of how one catches a StandardException. I guess in > my case it should be something like this: > > ConstantAction csca = new CreateSchemaConstantAction(schemaName, (String) > null); > try { > csca.executeConstantAction(activation); > } catch (StandardException se) { > if (se.getMessageId().equals(SQLState.LANG_OBJECT_ALREADY_EXISTS)) { > // Ignore "Schema already exists". > // Another thread has probably created it since we checked for it > } else { > throw se; > } > } > > Does this look OK? Yes. Dan.