db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: VOTE: Principles of sharing code
Date Fri, 28 Oct 2005 21:53:09 GMT
Thanks, Kathey. I still don't understand the scenario you're describing. 
It seems to me that application A never saw the bug fix at all because 
the shared code was always shadowed by the version which application B 
needed. However, the following scenario could occur and might be akin to 
the problem which is troubling you:

o Two applications, EmbeddedApp and ClientServerApp run in the same VM.

o EmbeddedApp contains derby.jar(rev 1)

o ClientServerApp contains derbyclient.jar(rev 3)

o classpath=EmbeddedApp;ClientServerApp

o ClientServerApp wants an important bug fix in shared code available in 
Derby rev 4. However, after upgrading to derbyclient.jar(rev 4), 
ClientServerApp still can't enjoy the bugfix because the improved shared 
code is shadowd by the old, buggy version in EmbeddedApp. The only way 
that ClientServerApp can enjoy this bugfix is if EmbeddedApp upgrades to 
use derby.jar(rev 4).

It's worth pointing out that this problem already exists today:

o Two applications, ClientServerApp1 and ClientServerApp2 run in the 
same VM.

o ClientServerApp1 contains derbyclient.jar(rev 1)

o ClientServerApp2 contains derbyclient.jar(rev 3)

o classpath=ClientServerApp1;ClientServerApp2

o ClientServerApp2 wants an important bug fix in shared code available 
in Derby rev 4. However, after upgrading to derbyclient.jar(rev 4), 
ClientServerApp2 still can't enjoy the bugfix because the improved code 
is shadowd by the old, buggy version in ClientServerApp1. The only way 
that ClientServerApp2 can enjoy this bugfix is if ClientServerApp1 
upgrades to use derbyclient.jar(rev 4).

The authority which owns this VM and classpath has to coordinate the two 
applications.

Our users are already exposed to this problem. I think that the benefits 
of code sharing are significant enough that they warrant slightly 
increasing this exposure.

Regards,
-Rick



Kathey Marsden wrote:

>Rick Hillegas wrote:
>
>  
>
>>>>Scenario 1 - Fixing a Bug
>>>>
>>>>If I have it right the issue of "masking" comes up only when you have
>>>>a mixed version environment.  Let's say the user is running with the
>>>>10.2 embedded driver and the 10.3 client driver.  Hopefully the user
>>>>tells us "I'm using both 10.2 and 10.3."  Then we would fix the bug in
>>>>both the 10.2 and 10.3 common code.
>>>>
>>>>If for some reason the user doesn't tell us this, we may fix the bug
>>>>in the wrong version the first time, but after getting more info from
>>>>the customer it will be clear that the bugfix should be ported to the
>>>>other branch.
>>>>
>>>>We could have a policy that a common bug fix should be ported to all
>>>>releases currently available and supported, but that seems like
>>>>overkill and against the policy of "scratch your own itch" -- a bug
>>>>should be fixed in the versions that matter to the user who has the
>>>>bug.
>>>>
>>>>So I would argue when you do your test, you should make the fix in
>>>>both versions of the common code and you should see no problem.
>>>>
>>>>
>>>>  
>>>>        
>>>>
>>>Now *that* is user impact, developer impact and support impact.   The
>>>fact that the bug fix revision level will regress with mixed jars if the
>>>new jar is not first,  is an important product behaviour change to
>>>mention.  I don't fix a bug normally for a single end user.  I fix a bug
>>>for a product that is deployed (hopefully) to thousands of users.  You
>>>are saying I need to know the configuration of all of those sites and
>>>deal with them one by one. It's impossible.  And this is not 10.2 and
>>>10.3 mixing that we are talking about.  Installing some product with the
>>>embedded driver at  10.2.1.1 might mask a client install at 10.2.1.19
>>>and make something that is working just fine break in strange ways,
>>>where as now the two are totally independent.  
>>>
>>>      
>>>
>>I have lost the track of this argument. I am confused by the phrase
>>"the bug fix revision level will regress with mixed jars". Can you
>>help me understand how behavior regresses, that is, becomes worse? I'm
>>only seeing two cases here:
>>
>>o The bug fix is applied to the wrong Derby version (the second one in
>>the classpath), in which case it is a NOP. The experience for the
>>customer will be that the bug was not fixed. However, no new
>>regressions are introduced.
>>
>>o The bug fix is applied to the correct Derby version (the first one
>>in the classpath). This fixes the bug for the customer. But what
>>behavior is made worse here?
>>
>>A concrete example would help. Thanks.
>>
>>
>>    
>>
>This is the circumstance that Dan was talking about where jars are mixed
>by circumstances.  I quote Dan's July 13 (Wow)
>JIRA-289 comment.  Dan said ....
>.
>  
>
>>In case it's not clear, this is the type of situation I'm talking about.
>>Application A is a client server application and requires Derby client
>>    
>>
>10.2
>  
>
>>Application B is a local embedded Derby application and requires Derby
>>    
>>
>engine 10.3
>  
>
>>Now I want to run a client to A and B in the same JVM for some reason,
>>    
>>
>maybe portlets, maybe multiple applications
>  
>
>>in the same app server, maybe application B requires access to
>>    
>>
>application A.
>  
>
>>This would be supported with the current model, complete flexibility
>>    
>>
>because the code bases are separate.
>  
>
>>So do we want to lose this flexibility, or support it with the shared
>>    
>>
>code model?
>
>
>Now lets change the versions a bit and say  our classpath is in this
>order   derby.jar;derbyclient.jar
>Application A is at 10.2.1.2   -  They just last week got a critical bug
>fix in shared code and are happy to be running again.
>Application B is at 10.1.2.1    -  They are running fine too but
>planning to upgrade next week.
>
>next week rolls around and the user installs their CD from Application B
>which contains 10.2.1.1 .
>Application B is working great,  but because the new derby.jar masks the
>fix in derbyclient.jar, Application A is broken again.
>
>I agree that jar mixing is an unfortunate reality,  but it is a reality
>and has to stay safe and legal at least for a period of time while work
>is done to make it rare.
>
>
>Kathey
>
>
>
>  
>


Mime
View raw message