>>>>> "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.
DJD> Within the engine code it would be a StandardException that was being
DJD> ignored, the engine throughout uses StandardException as its exception
DJD> model, and converts to JDBC'S SQLException at the interface to the
DJD> application. The code would catch StandardException and if its message
DJD> identifier (which will translate to the SQLState in the SQLException)
DJD> was the expected one it would ignore it, otherwise re-throw the
DJD> exception. I'll look for an example and post it.
DJD> I'm still thinking if this is the correct solution for this case, most
DJD> likely it is.
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?
--
Øystein
