[Glass] Conflicts when using *String and Unicode* based indexes in GemStone 3.2 and Seaside

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

[Glass] Conflicts when using *String and Unicode* based indexes in GemStone 3.2 and Seaside

Dale Henrichs-3
In 3.2 the  offsets for the System class>>_sessionStateAt:put: family of methods were changed at the system level (a new block of gemstone private session state offsets was allocated) without changing the corresponding offsets in the  System class>>_sessionStateAt:put: methods.

Seaside uses _sessionStateAt:put: to count the number of requests handled among other things and it turns out that the range used by Seaside happens to overlap the session state used by Unicode16 class>>usingUnicodeCompares (which is used to indicate whether or not unicode compare mode is in effect or not).

The #usingUnicodeCompares method  is used by the indexing subsystem to determine whether or not Strings are allowed to be used in Unicode indexes or not ... 

Soooo, I will be pushing out a new fix for Seaside3 ... probably 3.1.1.2 with a fix for this bug[1] and a couple of other bugfixes[2] that were queued up (known bugfixes). If there is a bugfix for Seaside3.1 that you've been waiting on that's not on the list[2], now is a good time to bring it to my attention.

Dale 


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Conflicts when using *String and Unicode* based indexes in GemStone 3.2 and Seaside

Dale Henrichs-3
You are in a maze of twisty little messages that all look alike...

I'm afraid that in sending email back and forth with another engineer working on the problem we got our wires crossed...

The message _sessionCacheStatAt:put: is used in Seaside while the message _sessionStateAt:put: is the message that overlaps with the field where  #usingUnicodeCompares is stashed ... 

It is not correct to say that Seaside interferes with  *String and Unicode* based indexes in GemStone 3.2...

Sorry for the confusion, but I didn't notice the difference until I went to fix the bug and noticed that were were talking about apples and oranges:)

We do have a case in the wild, where something in the image is using _sessionStateAt:put: ... we'll just have to continue searching:)

Sorry for the noise,

Dale


On Wed, Jul 2, 2014 at 2:35 PM, Dale Henrichs <[hidden email]> wrote:
In 3.2 the  offsets for the System class>>_sessionStateAt:put: family of methods were changed at the system level (a new block of gemstone private session state offsets was allocated) without changing the corresponding offsets in the  System class>>_sessionStateAt:put: methods.

Seaside uses _sessionStateAt:put: to count the number of requests handled among other things and it turns out that the range used by Seaside happens to overlap the session state used by Unicode16 class>>usingUnicodeCompares (which is used to indicate whether or not unicode compare mode is in effect or not).

The #usingUnicodeCompares method  is used by the indexing subsystem to determine whether or not Strings are allowed to be used in Unicode indexes or not ... 

Soooo, I will be pushing out a new fix for Seaside3 ... probably 3.1.1.2 with a fix for this bug[1] and a couple of other bugfixes[2] that were queued up (known bugfixes). If there is a bugfix for Seaside3.1 that you've been waiting on that's not on the list[2], now is a good time to bring it to my attention.

Dale 



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass