Rick Hillegas (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Rick Hillegas updated DERBY-700:
--------------------------------
Fix Version/s: 10.3.0.0
(was: 10.2.0.0)
It appears that fixing this bug will require us to agree on some mechanism for
caching VM-global Derby state. This seems to be an architectural decision which
requires careful thought and experiment. I think we should defer this to a
future release. I am moving this to 10.3 because thatt's the next release
available in the dropdown. I agree with Kathey that this is a good candidate
for a bug fix release in the 10.2 lineage.
If anyone has ideas on this one, please post them. I have been stumped
by this one so far. As I posted earlier I think one approach simply
needs a way to uniquely identify the current JVM, and also some way
to coordinate a sync block across 2 class loaders. So far I have
been convinced by dan and david that using System properties is the
wrong approach.
As kathy has said the consequences of this is that
user may corrupt the db so it is bad. We should document either in
release notes or the main documentation that Derby does not currently
support accessing the same db, in the same JVM, from 2 separate class
loaders. System properties in general are a problems for this
configuration, and I believe we do no testing of the configuration
either. Any opinions on where this info should show up.
As this is an unsupported configuration, I believe that it should not
hold up the 10.2 release, but I also agree that whenever we get an
agreed upon fix it should go into the next release of all current
releases.
