links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Magma Commit Strategies
Last updated at 10:59 pm UTC on 13 August 2015
Q: Where should my application send #begin, #commit, messages?

A: There are several approaches that can be used.

1) Reference the MagmaSession via an instVar of the domain.
A variable which references a MagmaSession when that object is committed will reference the materializing session upon materialization.

This allows programs to be written to say, something like:
  self session commit: [ ... ]

This approach can be convenient, but OO purists prefer to have the domain more decoupled from the method of persistence.

2) Program-controlled transactions: You signal commit notifications in your domain. A controller catches these notifications and applies them to its session. When no controller is listening, the notifications are ignored, allowing testing of the domain with or without the database.
	name: aString
		MagmaSessionRequest signalCommit: [ name := aString ]

This approach gives the program control over when commits are performed. It also allows the user to be free of any concern about remebering to "save"; everything that requires a transaction will be committed without them thinking about it.

MagmaSessionRequests are harmless when Magma is not installed; they have no effect. You can use them even with only the Ma-Core package loaded, and no other Magma packages.

The only job your handler needs to do is provide the session which should handle that request. All that is required is to ask the incoming "req" argument, a MagmaSessionRequest, to #handleAndResumeUsing:. Like this:
	[ "... do something that signals MagmaSessionRequests..." ]
		on: MagmaSessionRequest
		do: [ : req | req handleAndResumeUsing: theSession ]

Many applications will require access to multiple different Magma databases, which has different implications for each application. From Magma's perspective, it is the applications responsibility to handle SessionRequests from its domain in the way appropriate for itself.

3) User-controlled transactions, with auto-begin: With this approach, the user is always in a transaction. The program provides a "Save" or "Commit" button which the user occasionally presses as they modify the domain model. The program could also provide its own "Cancel" function (which would send #abort, followed by #begin to the MagmaSession) to provide a rudimentary undo function. To use auto-begin, your program does an initial #begin when connecting the session, then every commit should instead use #commitAndBegin instead of #commit. #commitAndBegin does the same as #commit, followed by #begin, but in one trip to the server instead of two.

4) User-controlled transactions This is the same as 3 except the user is in full control; decides when to begin, commit, abort, refresh, etc.