db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3618) Perform thread dump with ASSERTS with jdk 1.5 or higher
Date Tue, 15 Jul 2008 19:43:31 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613707#action_12613707

Kathey Marsden commented on DERBY-3618:

So it looks like you have stumbled upon an old and debated topic of shared code.  There was
a long conversation about this a long time ago, but basically there are some serious problems
with sharing code between engine and client if mixed jar versions are used, because you don't
know what version will be used.
There may also be some issues with sealing violations with shared code that I don't fully
understand (see DERBY-1125)

I thought that the conclusion was that there would be a shared directory created but that
that code would actually only go into client until a  real shared code solution was found.
 Also it was determined that it was ok for constants like Attribute.java and SQLState.java
to go in because the constants get compiled out.

Despite that, it looks like the SanityManager code made its way into the shared directory
and is actually shared between engine and client.
 I am guessing it was decided that it was ok to share the SanityManager code because it doesn't
affect production (insane) builds, but that's just a guess.

Now for your changes,  I don't think Monitor and all its dependencies should be shared code
and go into derbyclient.jar.  I think the best solution would be to build the trace info into
the assertion message and eliminate use of Monitor in the new code.  It doesn't make sense
when used in the context of client anyway.  As for JVMInfo  I tend to think as well, that
the cleanest thing is not to use it. You can attempt a Class.forName() on a class only available
in JDK 1.5 or higher as a quick check of the vm level.

> Perform thread dump with ASSERTS with jdk 1.5 or higher
> -------------------------------------------------------
>                 Key: DERBY-3618
>                 URL: https://issues.apache.org/jira/browse/DERBY-3618
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>    Affects Versions:
>            Reporter: Kathey Marsden
>            Assignee: Erlend Birkenes
>            Priority: Minor
>         Attachments: DERBY-3618_1.diff, DERBY-3618_2.diff, DERBY-3618_3.diff, DERBY-3618_4.diff
> It would be good to have a stack traces for all threads dump to the derby.log when an
assertion occurs with JVM's that support it.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message