[Glass] External tasks do not recognize new methods after commit - only after restart !?!?!?!?!

[Dale Henrichs]

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:
>
> 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
>
> [1] https://github.com/GsDevKit/GsDevKit/issues/129
> [2] https://github.com/glassdb/glass
> [3] https://travis-ci.org/github/GsDevKit/GsDevKit_home
>
> On 10/31/20 8:36 AM, Marten Feldtmann wrote:
>> SessionMethodTransactionBoundaryPolicy install 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/glass/attachments/20201103/d8fb8af5/attachment.htm>