db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendleton.de...@gmail.com>
Subject Re: Error XSDBB When Trying to Access DB From Windows, But Works In UNIX
Date Sat, 11 Dec 2010 02:50:12 GMT
> I'm trying to debug a strange error that just started occurring recently.

I think you've done a great job trying to identify the causes and triggers
of this problem.

I think you should open a new JIRA issue and start working directly with the
Derby developers. It seems possible that you are experiencing DERBY-4239,
but it may also be that you've encountered something completely new which
just happens to have the same symptoms.

To clarify a bit:
- accessing the DB using AIX & 64-bit JVM: works fine
- accessing the DB using Windows & 32-bit JVM: XSLA7 and XSDBB errors
- restored the DB then re-accessed it: XSDBB errors, but not XSLA7 errors.

Am I understanding correctly?

Are the two JVM implementations identical (in version and vendor) other than
the 32-bit vs. 64-bit issue? Can you state exactly which Java environment(s)
you are using?

Is it the same exact database in these two environments? Is it mounted on
some sort of share-able file system? Or are you transporting it between
environments? If you are transporting it, what process do you use to do that?

> our errors, I upgraded to Derby 10.5.3 and reverted back to a version of the
> database that did not exhibit the problem.  Unfortunately, that did not seem
> to help

Perhaps the reverting-back isn't really restoring your database to a state
of complete health. That is, perhaps in the reverted-back state, even though
the problem doesn't exhibit, perhaps the database is still damaged, but in
some way that doesn't show the symptoms until the database grows.

In your JIRA entry, I recommend that you ask the developers if there are any
tools that you can use to verify *for sure* that the reverted-back copy of
the database is clean and healthy.

Alternatively, you could try taking the reverted-back copy, and doing an
export-import step to completely unload your data and load it into a fresh
clean copy of the database created under Derby 10.5.3, at which point you should
be more confident that the DERBY-4239 problem is not present in your database.
Then if the problem still occurs at that point, that would be yet another
useful data point.

I'm sorry to hear that you're having these problems, but it sounds like you've
really got things narrowed down well, so hopefully you will be able to get
a quick resolution of your problem from the developer community.



View raw message