[GemStone-Smalltalk] Transcient instance variable

Tue Nov 11 06:29:08 PST 2014

Paul,
Interesting idea: we do need the stored values since we do have domain code that compares updated vs. original.
I do have some concerns. Aside from having to deal with unintended commits (as you mentioned), we would also add some complexity to our development environment. 

Right now we're able use VW with an 'in-memory' domain model. Great for debugging and SUnit tests.  The same domain code runs in the dev VW image as in GS (the deployed web server image has no domain code). If we update the domain instance in VW we'd have to unwind it in a pseudo-abort.

Storing the updates in a data wrapper is working well for us, since the final 'save' is an explicit domain update. We can do a lot of pre-save model validation. Each GS call is a RESTful call that rebuilds the data wrapper model, makes updates, and sends the result. All of which is done with no updates to domain objects until a 'save' is done. Each call is wrapped in a 'current context' that holds all the data wrappers, keyed so that we can find a corresponding wrapper for a domain object.

Most 'read' calls are now under 50ms.  Read + pending updates are 100ms to 200ms, as are the saves. The problem is that some behaviours reference large collections. In the past we wrapped every referenced domain object if there were any pending updates. Now we only wrap those with known pending updates. This introduced a heterogeneous model with wrapped and unwrapped instances. 

Not a problem, but the code would be simpler if there were only domain objects in mix (assuming the impact on performance was minimal).  That's the change I'm looking at.  Right now I'm leaning towards a 'dataWrapper' instVar on the domain root class that we would clear prior to a commit. Having a notNil instVar during a read would be an error condition. 

Bob 

On Monday, November 10, 2014 6:01 PM, Paul Baumann via GemStone-Smalltalk <gemstone-smalltalk at lists.gemtalksystems.com> wrote:

Hi Bob,

It seems like you are currently thinking of using the dataWrapper to note the new change. Consider if it will suit your needs better to use your dataWrapper to note the values before the first inst var change (like with a shallow copy), and allow the change to be made to the inst vars. The shallowCopy can be registered in some manager and the dataWrapper inst var of the copy can refer to the original object.

assignDataWrapper
                dataWrapper isNil ifTrue: [
                                dataWrapper := self copy.
                                copy dataWrapper: self.
                                (SessionTemps current at: #ChangeManager ifAbsentPut: [Array new])
                                                add: dataWrapper.
                ].
                ^dataWrapper

foo: newValue
                self assignDataWrapper.
                foo := newValue

foo
                ^foo

This approach performs better because changes to objects are less frequent than access to variables. The cost of making a change is the creation of a copy and adding it to some managed collection. The code needs to make consistent use of the custom setter methods, or else you'd try to hook some generic object dirtying code.

The ChangeManager can be defined however you want changes to survive. You can detect changes both at the object level and by the manager. You'd probably either do transaction changes through your ChangeManager or notify the manager afterwards (note that #continueTransaction has a notification bug). If your dataWrapper/copy is a committed object then you'd know that an unmanaged commit happened (the inst vars may now also contain changes from another session). If ChangeManager has copies that differ from what the originals noted for your session then you might have had an unmanaged begin/abort/continue transaction.

Regards,

Paul Baumann

From:GemStone-Smalltalk [mailto:gemstone-smalltalk-bounces at lists.gemtalksystems.com] On Behalf Of via GemStone-Smalltalk
Sent: Monday, November 10, 2014 16:52
To: gemstone-smalltalk at lists.gemtalksystems.com
Subject: Re: [GemStone-Smalltalk] Transcient instance variable

Paul,
Thanks for the note on 'System rcValueCache'. I can see use using it for other cases.

For the 'data wrapper' code change I'm considering performance is key. The check for updated values would be done on each in 'get' method, so anything that slows that down would be noticeable. 

I was thinking of code like... (we're still brainstorming this)

foo
    ^self getUpdatedValueAt: #foo with: foo

getUpdatedValueAt: aKey with: aValue
    self dataWrapper isNil ifTrue: [^aValue].
    ^self dataWrapper getUpdatedValueAt: aKey with: aValue  "where aValue is answered if there are no updates for2 #foo"

...we may just do this and take responsibility for clearing the data wrapper instVar just prior to a commit.

Bob

On Monday, November 10, 2014 12:55 PM, Paul Baumann via GemStone-Smalltalk <gemstone-smalltalk at lists.gemtalksystems.com> wrote:

Re-send to list...

From:Paul Baumann 
Sent: Monday, November 10, 2014 10:47
...
Subject: RE: [GemStone-Smalltalk] Transcient instance variable

Hi Bob,

"System rcValueCache" is flushed  with a view/transaction change (commitTransaction, abortTransaction, beginTransaction, continueTransaction). Here is an example that shows view-transient behavior:

| anObject get0 get1 |
System beginTransaction.
anObject := Object new.
System rcValueCacheAt: #plbTest put: #remembered for: anObject.
get0 := System rcValueCacheAt: #plbTest for: anObject otherwise: nil.
System commitTransaction.
get1 := System rcValueCacheAt: #plbTest for: anObject otherwise: nil.
Array with: get0 with: get1

anArray( #'remembered', nil)

Your domain object can use itself to retrieve by-reference attributes. A view-transient attribute would be like this:

viewTransient_plbTest
                ^System rcValueCacheAt: #plbTest for: self otherwise: nil

viewTransient_plbTest: anObject
                System rcValueCacheAt: #plbTest put: anObject for: self

A session-transient attribute would be like this:

sessionTransient_plbTest
                |dict |
                ^(dict := SessionTemps current at: #plbTest otherwise: nil) notNil
                                ifTrue: [dict at: self otherwise: nil].

sessionTransient_plbTest: anObject
                (SessionTemps current at: #plbTest ifAbsentPut: [IdentityDictionary new])
                                at: self put: anObject.

A wrapper object held in an object attribute can be used for better performance when needed. Your domain object would have an attribute that holds information that can find cached data quicker. If the attribute is nil then the no lookup is necessary (saving a search). If the attribute is not nil then it can be something like a reserved index position within a known location (not strongly referenced) that would contain the data. Years ago I had prototyped a cache framework that was able to use a special wrapper for weak references to related objects. It can be done--if you really need that level of performance.

Paul Baumann

From:GemStone-Smalltalk [mailto:gemstone-smalltalk-bounces at lists.gemtalksystems.com] On Behalf Of via GemStone-Smalltalk
Sent: Monday, November 10, 2014 08:25
To: gemstone-smalltalk at lists.gemtalksystems.com
Subject: [GemStone-Smalltalk] Transcient instance variable

I'm considering some refactoring that would benefit from having access to transcient instance variables.
Something like SessionTemps, but stored on an instance variable and cleared on each abort or commit.
It would be used to store pending updates. We do that now with a wrapper object, which works fine, 
but the code would be cleaner if the domain object wrapped the pending updates instead.

Anything like that available?

Thanks for any suggestions,
Bob Nemec
HTS

________________________________

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
GemStone-Smalltalk mailing list
GemStone-Smalltalk at lists.gemtalksystems.com
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

________________________________
 This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
GemStone-Smalltalk mailing list
GemStone-Smalltalk at lists.gemtalksystems.com
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20141111/0cfc8ef9/attachment-0001.html>