db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1428) Generating derby properties on the fly can lead to non-deterministic engine startup behavior
Date Mon, 19 Jun 2006 14:37:30 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1428?page=all ]

Rick Hillegas updated DERBY-1428:
---------------------------------

    Description: 
A Heisenbug can arise if more than one embedded Derby application runs in the same VM and
at least one of them generates derby properties on the fly. Here's the problem scenario:

o The customer runs two embedded Derby apps in the same VM: EmbeddedApp and OtherApp.

o EmbeddedApp generates derby properties on the fly before connecting to a database and triggering
engine startup.

o Whether the engine picks up those generated properties depends on whether EmbeddedApp or
OtherApp runs first.

Here are two workarounds for the problem:

1) Don't generate derby properties on the fly. Instead, specify them on the VM startup command.
Or specify them in a $DERBY_HOME/derby.properties file which is generated before the VM comes
up and which does not change during the lifetime of the VM.

2) If you can't do (1), then modify the VM startup script so that the self-configuring EmbeddedApp
runs first.


  was:
A Heisenbug can arise if more than one embedded Derby application runs in the same VM and
at least one of them generates derby properties on the fly. Here's the problem scenario:

o The customer runs two embedded Derby apps in the same VM: EmbeddedApp and OtherApp.

o EmbeddedApp generates derby properties on the fly before connecting to a database and triggering
engine startup.

o Whether the engine picks up those generated properties depends on whether EmbeddedApp or
OtherApp runs first.

Here are two workarounds for the problem:

1) Don't generate derby properties on the fly. Instead, specify them on the VM startup command.
Or specify them in a $DERBY_HOME/derby.properties file which is generated before the VM comes
up and which does not change during the lifetime of the VM.

2) If you can't do (1), then modify the VM startup script so that it forces the applications
to run in a deterministic order.



In workaround (2) be explicit about the order in which the applications have to run.

> Generating derby properties on the fly can lead to non-deterministic engine startup behavior
> --------------------------------------------------------------------------------------------
>
>          Key: DERBY-1428
>          URL: http://issues.apache.org/jira/browse/DERBY-1428
>      Project: Derby
>         Type: Bug

>   Components: Store
>     Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.2.2,
10.1.2.3, 10.3.0.0, 10.1.2.4, 10.1.2.5, 10.1.4.0, 10.1.3.1
>     Reporter: Rick Hillegas

>
> A Heisenbug can arise if more than one embedded Derby application runs in the same VM
and at least one of them generates derby properties on the fly. Here's the problem scenario:
> o The customer runs two embedded Derby apps in the same VM: EmbeddedApp and OtherApp.
> o EmbeddedApp generates derby properties on the fly before connecting to a database and
triggering engine startup.
> o Whether the engine picks up those generated properties depends on whether EmbeddedApp
or OtherApp runs first.
> Here are two workarounds for the problem:
> 1) Don't generate derby properties on the fly. Instead, specify them on the VM startup
command. Or specify them in a $DERBY_HOME/derby.properties file which is generated before
the VM comes up and which does not change during the lifetime of the VM.
> 2) If you can't do (1), then modify the VM startup script so that the self-configuring
EmbeddedApp runs first.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message