Ø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.
