db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Commented: (DERBY-230) "Schema already exists" when creating a table
Date Thu, 21 Apr 2005 14:07:11 GMT
Øystein Grøvlen wrote:

>>>>>>"ØG(" == Øystein Grøvlen (JIRA) <derby-dev@db.apache.org>
>     ØG(> As far as I can understand, the problem is in
>     ØG(> DDLConstantAction.getSchemaDescriptorForCreate() which first
>     ØG(> tries to get a SchemaDescriptor and if none exists will
>     ØG(> create one.  What probably happens is that a thread detects
>     ØG(> that the schema does not exist, but when it tries to create
>     ØG(> the SchemaDescriptor, another thread has already done that.
>     ØG(> There is at least two possible ways to fix this:
>     ØG(> 1. Make getSchemaDescriptorForCreate() synchronized.  (I have
>     ØG(> tested this and it solves the problem).
>     ØG(> 2. Ignore the "Schema already exists" exception from
>     ØG(> executeConstantAction.  The subsequent getSchemaDescriptor
>     ØG(> will then get the SchemaDescriptor created by the other
>     ØG(> thread.
> Being new to Derby, I am not quite sure which alternative should be
> preferred here.  Making the method synchronized is the simplest
> alternative, but I see that no other method of DLLConstantAction is
> synchronized.  

This is not the correct solution. There are other ways that schemas come
into existence that do not go through this method, most extreme would be
a rollback of a drop schmema statement.
[As an aside traditionally Cloudscape did not use synchronized *static*
methods as there were locking issues related to class loading - this was
from jdk 1.1 days, have those issues been fixed now?]

> For the second alternative, I looked around the code without finding
> any similar case where a SQLException is ignored.  Hence, I am
> wondering whether it is kosher to do it this way.  Is there any Derby
> policy that can guide me in choosing between the alternatives?

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


View raw message