db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Self-configuring embedded Derby applications
Date Mon, 19 Jun 2006 17:15:07 GMT
Hi Charlie,

Thanks for your quick response.

Charlie Kelly wrote:

> Hi Rick,
>
> We use Derby "deeply embedded" within Eclipse (osgi) and JBoss 
> aaplications in conjunction with Hibernate object-relational mappings,
> therefore, we can't always control when the application makes calls to 
> the Derby jar.
>
> We use Hibernate+Derby in two ways:
>    1) a semi-automated process that generates schemata from our object 
> model
>    2) a runtime process that passes schemata and Hibernate+Derby 
> properties into the application
>
> The properties are static with respect to our object model, but 
> dynamic from osgi and JBoss perspectives.

>
> Thanks
> Charlie Kelly
>
> P.S. What is a "Heisenbug"?

Sorry for the jargon. It's a term which Jim Gray coined for bugs which 
arise from non-deterministic behavior and which can disappear when you 
instrument the application to look for them.

Regards,
-Rick

>
>
>
>
> Rick Hillegas wrote:
>
>> Dear Derby users,
>>
>> I would like to understand if anyone thinks that they might be 
>> affected by the following issue. This issue affects customers who do 
>> the following:
>>
>> o Run an embedded Derby application which generates its own Derby 
>> properties on the fly.
>>
>> o In the same VM, run other JDBC applications. These other 
>> applications could request Connections to DB2, Oracle, Derby, or any 
>> other database.
>>
>> In general, we recommend against generating Derby properties on the 
>> fly. This general problem is described in DERBY-1428. However, the 
>> Derby mainline (slated to become release 10.2) expands this problem, 
>> as described in DERBY-1429. For a workaround, see the Release Note 
>> attached to DERBY-930.
>>
>> Here is more detail on this issue:
>>
>> a) With JDBC4, vendors mark their jar files to indicate the names of 
>> jdbc drivers in those jars. During the lifetime of a vm, the very 
>> first request for a Connection causes the DriverManager to look 
>> inside all of the jars and register all indicated jdbc drivers.
>>
>> b) When our embedded driver registers itself, it also boots the 
>> engine, using whatever derby properties are currently visible. 
>> Typically, the engine stays booted for the lifetime of the vm.
>>
>> This can cause a Heisenbug in the following scenario:
>>
>> o The customer runs two applications in the same vm: EmbeddedApp and 
>> OtherApp.
>>
>> o Before getting its first Connection, the EmbeddedApp hand-crafts 
>> its own derby properties to configure the engine's behavior.
>>
>> o OtherApp could be an application which uses the Derby client driver 
>> or some other jdbc driver.
>>
>> o If OtherApp runs before EmbeddedApp, then the engine will boot 
>> without the hand-crafted properties.
>>
>> o It may not be deterministic whether OtherApp or EmbeddedApp runs 
>> first. Sometimes you get the right engine properties and sometimes 
>> you don't.
>>
>> It is worth pointing out that this Heisenbug can occur today, 
>> pre-JDBC4, if OtherApp is another embedded Derby application. 
>> JDBC4-driver-autoloading broadens the family of affected scenarios.
>>
>> I would like to understand how much the family is broadened. Please 
>> let me know if you think this problem will affect you.
>>
>> Thanks,
>> -Rick
>>
>>
>>
>>
>>
>
>


Mime
View raw message