Issue 277 in glassdb: rethink default SymbolList position for SessionMethods SymbolDictionary

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Issue 277 in glassdb: rethink default SymbolList position for SessionMethods SymbolDictionary

glassdb
Status: Accepted
Owner: [hidden email]
Labels: Type-Defect Priority-Medium GLASS-Server Version-1.0-beta.8  
bugid-41336

New issue 277 by [hidden email]: rethink default SymbolList position  
for SessionMethods SymbolDictionary
http://code.google.com/p/glassdb/issues/detail?id=277

Pieter Nagel reported a problem with installing GLASS into an existing  
GemStone application that had been upgraded from 32bit:

   
http://forum.world.st/Bootstrapping-GLASS-into-extent-converted-from-GS32-bit-6-5-7-5-to-GS64-2-4-4-4-td3319086.html

In the end he determined that the problem was due to the ordering of the  
SessionMethods symbol dictionary. Explanation from Pieter:

We found the problem.

It seems that ordering of packages in the users' symbollist is important,  
because compiledMethodAt: looks in each package in order and answers the  
first session override it finds.

Normally, extent0.dbf, before bootstrapping GLASS using  
installMaster24.topaz, the ordering of symbol dicts is: UserGlobals,  
Globals, Published. The bootstrap process seems to be hard-wired to create  
SessionMethods before Globals, so one ends up with UserGlobals,  
SessionMethods, Globals, Published.

Through a mechanism which I as yet don't understand, the package inside  
UserGlobals is made the bearer of the methodDict where Behavior session  
methods overrides are added to when compiled. But since UserGlobals  
contains the first package, it is also where these methods are looked up  
again, so it all works.

However, in our production database, the ordering of symbol dicts was <lots  
of our dictionaries>, then Globals, Published, UserGlobals.  
installMaster24.topaz once again created SessionMethods directly before  
Globals, which means that session method overrides were now first searched  
for in the package inside SessioMethods before UserGlobals. However,  
compiled session methods still went to the methodDict inside the package in  
UserGlobals. This caused our observed behavior of methods seeming to not  
chang after being filed in.

When we fixed the ordering of our symbol dicts to be <lots of our  
dictionaries>, UserGlobals, Globals, Published, we were able to sucessfully  
run through installMaster24.topaz to the end.

It seems that the way in which the position to create SessionMethods is  
chosen when it is absent is a bit brittle, since it makes too many prior  
assumptions about the relative ordering of Globals and UserGlobals.

--------------

They had ordered their symbol list as follows:

   <lots of our dictionaries>, then Globals, Published, UserGlobals

with UserGlobals at the end and when SessionMethods was installed the order  
became:

   <lots of our dictionaries>, SessionMethods, Globals, Published,  
UserGlobals

Because there are some methods in UserGlobals (the default override  
location) that must override methods in SessionMethods and since in their  
universe, the SessionMethods dictionary was in front of instead of behind  
(for lookup purposes), the overrides never took place.

Not sure what the best way to handle this is ... but at a minimum should  
complain if SessionMethods symbolDictionary is ever in front of the target  
SymbolDictionary for GLASS ...