External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
Locked
External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
 
|
I noticed a problem I've never seen before:
I am working with Gemstone/S 3.5.1 and Jade 2.4.6. My development cycle is the following:
* Full Gemstone/S application is running with several answering Gemstone/S tasks (http)
* I change code in Jade and do a commit
* Then I execute something in our UI application to test the changes
This works very well - but today I noticed, that when I add a new method and call it in my application the answering tasks throw an error and tell me, that they do not understand the new method. I've never seen this before :-(
When I shut down the database and restart the application again everything is ok ... up to the time when I add a new method and want to execute it in the ansering tasks.
_______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
|
|
Ok, it works in a clean Gemstone 3.5.1 without problems ... so it must be another reason for it ...
Marten
_______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
|
|
In reply to this post by GLASS mailing list
Hi Marten,
While not common, this sort of problem happens to me once or twice a year and is pretty confusing till you figure out what is happening. A common cause of this problem is that the running application is using an instance of a _different_ class; and by “different class” I mean a class with a different OOP (and therefore a different MethodDictionary). The class probably has the same name and inherits from the same superclass, but is not _the same_ class so adding a method to one does not change the other. This can happen when you add or remove instance variables, because doing so will create a new class _version_. (It can also happen when you remove a class from a SymbolDictionary then reload it while another session has a reference to an instance of the old class, but this isn’t as common as simply changing an instance variable.) So, is there a chance that you added/removed/renamed an instance variable shortly before the problem started? Note that Jade has a dialog that offers to migrate all instances as part of a class schema change. If the instance being used in the application is committed then this should catch it. James > On Oct 29, 2020, at 12:42 AM, Marten Feldtmann via Glass <[hidden email]> wrote: > > I noticed a problem I've never seen before: > > I am working with Gemstone/S 3.5.1 and Jade 2.4.6. My development cycle is the following: > > * Full Gemstone/S application is running with several answering Gemstone/S tasks (http) > * I change code in Jade and do a commit > * Then I execute something in our UI application to test the changes > > This works very well - but today I noticed, that when I add a new method and call it in my application the answering tasks throw an error and tell me, that they do not understand the new method. I've never seen this before :-( > > When I shut down the database and restart the application again everything is ok ... up to the time when I add a new method and want to execute it in the ansering tasks. > > > _______________________________________________ > Glass mailing list > [hidden email] > https://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
|
|
In reply to this post by GLASS mailing list
Marten, You have submitted an HR and we'll use the HR to characterize and resolve your issue, but since you asked a question on this list, I will fill in some details about how things work here so that other developers are informed. You mention in the HR that you added a method to
CharacterCollection ... and since I assume that you are running as
DataCurator, that means that session methods are involved ...
session methods are special in that extension methods that you add
to classes in Globals as DataCurator (or any other non-SystemUser
user) are not added directly to the method dictionary of the
class, but stored in a separate dictionary (this is done because
you do not have the right permissions to write to the method
dictionaries of the classes in Globals). The method dictionary and methods, like all persistent objects are updated at commit boundaries, but in our vms, copies of the persistent methods are installed in method caches for performance reasons. When a method is modified during a commit, the method cache for all other sessions are refreshed at commit boundaries. Session methods use a different caching mechanism and that is were things are apparently breaking down in your system. In GLASS, the class SessionMethodTransactionBoundaryPolicy is used to track changes to session methods. An instance of SessionMethodTransactionBoundaryPolicy is installed at login at the same time that the session method "caches" are filled, when session methods are enabled. The instance of SessionMethodTransactionBoundaryPolicy is
notified at each transaction boundary and if any other session has
made a change to the session methods, then the session method
caches are cleared and reset ... Soooo, the fact that new (and changed?) session methods are not being updated on transaction boundaries, means that something has gone wrong with the installation of SessionMethodTransactionBoundaryPolicy or with the logic for refreshing the session method caches on transaction boundaries... As I said before, we'll work on addressing your specific issues
via the HR system, but if anyone else has any questions, let me
know. Dale
On 10/29/20 12:42 AM, Marten Feldtmann
via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
|
|
So, to make clear how this might affect your work:
We have a package with the pure model code (setter, getter etc) and a package with the "logic" code on top of that model mackage. This logic code package is changed more often and normally I can update a running system just by loading the "logic" code package - no downtime needed.
With the behaviour mentioned below, after such an update your code might fail: ALL running tasks WILL load the new code in the new version of the logic package (with thte next transaction) - but extension methods to base classes will not be seen by the processes and if your new logic code calls these method - it throws an exception.
This behaviour seems to be changed by the package Bootstrap-v34-dkh.264 - as pointed out by the GemtalkSystems support. Thanks for that.
Marten
_______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
|
|
I've to correct my message:
SessionMethodTransactionBoundaryPolicy install
did fix my problems
_______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
|
|
Marten, I'm glad that you were able to determine that something had perturbed `TransactionBoundaryDefaultPolicy current` and yes, `SessionMethodTransactionBoundaryPolicy install` will set things right again ... Of course, the million dollar question is "how did that happen?"
and in your HR you note that the only db that exhibits this
problem is one that had been upgraded and that is an interesting
observation. At this moment I don't have a smoking gun, but it is worth noting that I also don't have a test that confirms that the SessionMethodTransactionBoundaryPolicy is properly installed, so a regression in this area during upgrade could certainly fall between the cracks. So thanks, Marten for this information. I've opened issue #129 "Kernel class modifications not propagated to other sessions on transaction boundaries as expected"[1] with the first step of adding a test case(SessionMethodTransactionBoundaryPolicyTests>>testConfirmSessionMethodTransactionBoundaryPolicyInstalled): self assert: (TransactionBoundaryDefaultPolicy current isKindOf: SessionMethodTransactionBoundaryPolicy) Once, I've merged the new testcase into the glassdb/glass[2]
master branch, I'll trigger the GsDevKit/GsDevKit_home travis
tests[3], which has a coverage for upgrades for GemStone 2.4.4.1,
3.1.0.6, 3.3.9, 3.4.5, 3.5.0 and 3.5.4. The coverage is not a full
matrix of possible upgrade combinations, but should be enough to
get a read on the possible extent of the problems, if any. Of course at this point in time, if any of you listening in on this conversation haven't already done so, I'd suggest that it would be prudent to go ahead and confirm that the SessionMethodTransactionBoundaryPolicy in your db's are properly installed: TransactionBoundaryDefaultPolicy current isKindOf: SessionMethodTransactionBoundaryPolicy and if it is not a SessionMethodTransactionBoundaryPolicy, use
the following to do the repair: SessionMethodTransactionBoundaryPolicy install I would encourage any of you to report results/observations on
Issue #129[1] going forward. I'll report back the test results here when they become available
... travis has been overloaded recently so it might take a while
for the full set of tests to run:) Dale On 10/31/20 8:36 AM, Marten Feldtmann
wrote:
SessionMethodTransactionBoundaryPolicy install _______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
|
|
I've added the new test to glassdb/glass and updated the GsDevKit/GsDevKit_home tests to ensure that the unit tests are run on the upgraded extent and it turns out that all of the upgrades to 3.5.x are failing[1] and the only failure is the new SessionMethodTransactionBoundaryPolicyTests>>testConfirmSessionMethodTransactionBoundaryPolicyInstalled test ... this means that if you have upgraded to 3.5.x (including 3.5.x to 3.5.x upgrades ... see [2]) you should definitely run: SessionMethodTransactionBoundaryPolicy install System commit I will plan on having a fix for this issue (internal bug 49225)
for 3.5.5. Given the ease of repairing this issue, I wouldn't think you
should defer any upgrade plans you might have to wait for 3.5.5,
but that is up to you. Dale [1] https://travis-ci.org/github/GsDevKit/GsDevKit_home/builds/741019503 [2] https://travis-ci.org/github/GsDevKit/GsDevKit_home/jobs/741019513 On 11/1/20 11:19 AM, Dale Henrichs
wrote:
_______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
|
|
As a final followup to this issue, I have updated the
GsDevKit_home $GS_HOME/bin/upgradeStone script to reinstall the
SessionMethodTransactionBoundaryPolicy after an upgrade to 3.5.x
has been completed, so no need to manually patch after an upgrade
... If you want to follow along at home, you should run
`updateGsDevKit -gs` to pick up the new version of GsDevKit_home
and the updates to class (new
SessionMethodTransactionBoundaryPolicyTests) --- this is assuming
that you've already run the update I suggested back in October[1],
otherwise you should use `updateGsDevKit -gctsd` (this expression
basically updates and rebuilds everything except your stones:) Dale [1]
http://forum.world.st/recent-project-updates-for-3-5-4-and-upcoming-3-6-0-tt5123345.html On 11/3/20 8:49 AM, Dale Henrichs
wrote:
_______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: External tasks do not recognize new methods after commit - only after restart !?!?!?!?!
|
|
Thanks, that pretty nice !
Marten
_______________________________________________ Glass mailing list [hidden email] https://lists.gemtalksystems.com/mailman/listinfo/glass |
| Free forum by Nabble | Edit this page |