Class renaming and Class schema change vs GemTools

Hello,

I am encountering some difficulties while implementing some changes to
a class definition from GemTools (1.0-beta.8.6).

If I make a change to my class (name or instance variables) I get:
An operation that need to acquire the GcLock was not able to get the
lock within a reasonable amount of time.

This class or its 12 subclasses have no persistent instances.

Yesterday I got two of these messages when I tried to remove an
un-needed instance variable. Gemtools eventually froze (I waited for
more than one hour).  I stopped GemStone.  It restarted ok, but the
class hierarchy depending on the class being updated was strange.

There was a duplicate class entry in the browser. Exact same name and
class history (from the menu). And half of the subclasses were
displayed at the same level as my root class, instead of being under
their superclass.

The duplicate root class disappeared when I removed the subclasses
that were not at the right place in the browser.


I am getting the same GcLock problem when trying to rename a class.


Question:
1- What is this GcLock?  Is there a timing parameter that could be
increased somehow?
2- Should a class schema change be done in topaz instead of GemTools?
If yes, could you remind me how to do that? (including instance
migration).


Thanks,
Thierry

Thierry,

The GcLock is not related to class changes, so something else must be going on .... I'd be interested in more detailed stack information ...

Changing class definitions does involve some complex operations in GemTools, because we are trying to rebuild the class hierarchy rooted in the changed class to use the new version of the class ... When this process fails, you can get extra classes showing up in class browsers ... Accepting the class definition of the duplicate class (or classes) should clean things up but that depends upon how deep the hierarchy goes ... there are automated scripts that have been described in this list for other threads and we can rediscover them again ...

You can do things in topaz, but then you will have to manually redefine all of the subclasses and then do your own migrations to account for the new class versions ...

I'd like to understand the specific problem you are having so that we can fix the problem in GemTools ...

What version of GLASS are you using?

Dale

----- Original Message -----
| From: "Thierry Thelliez" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, March 14, 2012 9:38:28 AM
| Subject: [GS/SS Beta] Class renaming and Class schema change vs GemTools
|
| Hello,
|
| I am encountering some difficulties while implementing some changes
| to
| a class definition from GemTools (1.0-beta.8.6).
|
| If I make a change to my class (name or instance variables) I get:
| An operation that need to acquire the GcLock was not able to get the
| lock within a reasonable amount of time.
|
| This class or its 12 subclasses have no persistent instances.
|
| Yesterday I got two of these messages when I tried to remove an
| un-needed instance variable. Gemtools eventually froze (I waited for
| more than one hour).  I stopped GemStone.  It restarted ok, but the
| class hierarchy depending on the class being updated was strange.
|
| There was a duplicate class entry in the browser. Exact same name and
| class history (from the menu). And half of the subclasses were
| displayed at the same level as my root class, instead of being under
| their superclass.
|
| The duplicate root class disappeared when I removed the subclasses
| that were not at the right place in the browser.
|
|
| I am getting the same GcLock problem when trying to rename a class.
|
|
| Question:
| 1- What is this GcLock?  Is there a timing parameter that could be
| increased somehow?
| 2- Should a class schema change be done in topaz instead of GemTools?
| If yes, could you remind me how to do that? (including instance
| migration).
|
|
| Thanks,
| Thierry
|

I am using GLASS 1.0-beta.8.7.2 and GemTools 1.0-beta.8.6.

I think that I am back on my feet for now. I recreated some classes
and played with the SymbolList to remove a class.

But any class definition change does take forever.  And this seems to
be getting worse as the extent grows. Maybe I can show you that next
week at STIC?

Thanks,
Thierry

Depending upon what you are doing you can improve your migration times using GsDeployer, but there are caveats in it's use...

So far I haven't been able to find a fast, one-size fits all migration scheme.

Talking next week would be a good idea, if you're out of the woods for now ...

Dale

----- Original Message -----
| From: "Thierry Thelliez" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, March 14, 2012 11:13:04 AM
| Subject: Re: [GS/SS Beta] Class renaming and Class schema change vs GemTools
|
| I am using GLASS 1.0-beta.8.7.2 and GemTools 1.0-beta.8.6.
|
| I think that I am back on my feet for now. I recreated some classes
| and played with the SymbolList to remove a class.
|
| But any class definition change does take forever.  And this seems to
| be getting worse as the extent grows. Maybe I can show you that next
| week at STIC?
|
| Thanks,
| Thierry
|

Few minutes ago I needed to make another modification to one of the
involved classes.  Prior to accepting the change I turned off the auto
migration option under 'transactions' (there is no kept instance of
this class).  The commit was just a couple of second long...


Thierry

When you do that you are not automatically migrating any instances of the classes that have changed shape ... any instance reference the previous class history of the class which may or may not cause a problem ...

Dale

----- Original Message -----
| From: "Thierry Thelliez" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, March 14, 2012 4:56:19 PM
| Subject: Re: [GS/SS Beta] Class renaming and Class schema change vs GemTools
|
| Few minutes ago I needed to make another modification to one of the
| involved classes.  Prior to accepting the change I turned off the
| auto
| migration option under 'transactions' (there is no kept instance of
| this class).  The commit was just a couple of second long...
|
|
| Thierry
|

Yes, that's expected.  These classes in particular do not have
persistent instances.

But my point is that the the auto migration must be taking a lot of
time/resources searching for possible instances to migrate.  How is
the search done?  Reading all the pages?

Thierry

the auto migration code is not smart ... each class is migrated separately so you get an allInstances pass for each migration ...

In the general case it is not safe to defer migration until "the end" since the class you are changing could be on the stack or soon to be on the stack and the new methods expecting new state might be sent before "the end". if you are doing the class change in a live production system, it might not be safe to leave unmigrated instances lying around for your users to trip over. I have a todo list for upgrading the SS3 repository that can give some insight to the problems as well as some solutions that I've applied[1]...

If you know that it is safe to defer migration until a later date, you can afford to turn off auto migration and worry about the after effects later ...

The GsDeployer class has an option for doing a bulk migrate of a bunch of classes at once ... only making a single pass through the repository...so if you are going to turn off auto migration, it may be better to use the GsDeployer bulkMigrate method as there are a handful of things that you need to worry about when you're doing loads in general.

Dale

[1] http://code.google.com/p/squeaksource3/wiki/UpgradeToDoSs3ToRc2
----- Original Message -----
| From: "Thierry Thelliez" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, March 15, 2012 5:39:56 PM
| Subject: Re: [GS/SS Beta] Class renaming and Class schema change vs GemTools
|
| Yes, that's expected.  These classes in particular do not have
| persistent instances.
|
| But my point is that the the auto migration must be taking a lot of
| time/resources searching for possible instances to migrate.  How is
| the search done?  Reading all the pages?
|
| Thierry
|