Magma June 2007

magma@lists.squeakfoundation.org

10 participants
16 discussions

[Fwd: Re: Concurrently allocated sessions get into trouble]
by Keith Hodges 17 Jul '07

17 Jul '07

The code addressing this issue is in 207 cheers Keith > > I merged Magma server-kph.206, thanks for that, but I did not see any > code addressing this issue. So what guard did you use to protect the > opening of the sessions? Did you add a class-var? > > Regards, > Chris >

2 1

complete domain independence
by Chris Muller 12 Jul '07

12 Jul '07

I'm happy to report I have improved Magma so that the MagmaCollectionIndex is no longer required in the server image. This was a very annoying "exception" to the feature that the server does not need any domain classes. Custom index types are rightfully considered part of the domain, and requiring them (unnecessarily, it turned out) in the server means a completely static codebase in the server was not possible. Now, with r40, it will be. Oh, also, r40 will automatically upgrade legacy repositories. You'll see a warning once, a brief upgrade will occur and you're ready to roll with the r40 code. Further, it is planned that all future releases will be able to co-exist with r40. Just a few more things to do, r40 will be a worthwhile upgrade.. thanks for your patience. - Chris

2 3

Re: DB Transactions and UI
by Mariano Montone 01 Jul '07

01 Jul '07

Well, I have to say that Magma completely solves my problems. I have this seaside code. It calls the user editor. The transaction is kept among several requests. There's no transaction contention since locks are not used and optimistic concurrency control is used instead. You can add and remove groups to the user. If the user cancels, the transaction is aborted and changes are rolled back (automatic undo :)). If the user accepts, then the transaction commits and changes to the user are made effective. If there's a commit error, then the application can handle it. It displays a dialog informing the user of the error and then lets him edit again with a fresh copy. Sorry if this looks silly to you, but I don't know how to implement this kind of thing in an ORM. I'm the author of a PHP Web/ORM framework but achieving all these things is unfortunately not possible AFAIK. There's at least one bug in the code. I don't know how to catch the user intention of leaving the component by clicking on another link. If that happens, then the transaction is not aborted nor commited. Leaving the user in an unconsistent state and with a transactionLevelNumber = 1. What's more, later editions will not work because of this (the commit will be ignored as the transactionLevelNumber > 1). This is the code (note that I'm not a Seaside expert nor a Magma expert): editObject | session | session := self session magmaSession. session begin. [(body call: (APUserEditor on: self model)) ifTrue: [session commit] ifFalse: [session abort]. self viewObject] on: MagmaCommitError do: [:e | session abort. self inform: 'The user has been modified by another user. Edit the user again, please'. self editObject] Mariano 2007/6/29, Mariano Montone <marianomontone(a)gmail.com>: > > After having looked at the code, I see that an MagmaCommitConflict > exception is raised and an apportunity for the application to decide what to > do is given. That is exactly what I wanted. I didn't expect it to be > implemented like that (I'm used to some RDBMS worlds where this kind of > interaction with the DB is not possible, AFAIK). > > This looks very promising!! > > I'll be back after doing some tests. > > Thanks, Mariano > > 2007/6/29, Mariano Montone <marianomontone(a)gmail.com >: > > > > Chris, thanks for answering. Some comments: > > > > 2007/6/28, Chris Muller <asqueaker(a)gmail.com>: > > > > > > Hi Mariano, I have a couple of brief comments. > > > > > > The longer the transaction, the greater chance for for a commit > > > conflict. So how should a database handle this? > > > > > > I expect the application to decide what to do. Maybe the DB could raise > > a CommitConflict exception and maybe provide some restarts (ala Common Lisp > > condition system) for the application to decide how to go on. > > > > I can't speak for others, but Magma doesn't silently restart any > > > transactions, ever. That example sounds like mismanagement of a > > > dirty-read situation. > > > > > > I'm interested in this one. How does the application gets notified of a > > transaction need to restart? I think my problems could be solved depending > > on this. > > > > Thanks, Mariano > > > >

1 0

DB Transactions and UI
by Mariano Montone 29 Jun '07

29 Jun '07

Hello, this mail is quite off-topic. It is not related to magma itself (which I haven't have time to use lately), but to user interface design and databases. I think there are problems with the way db transactions work and how the user interacts with the application. I've been developing web applications so far, so I'll be describing a web UI. There are cases in which a user wants to perform several operations in a transactional way. That means he wants isolation: don't invade others view of the data until he has commited the changes (probably hitting an "accept" button); he wants consistency throughout the transaction execution; he wants atomicity and durability (these two ones are not a problem, everything is handled properly). The problem is that a user wants to work in a transactional way, but that is not supported by today databases. That's because transactions are meant to be extremely short and their lifetime cannot be associated to the UI transaction lifetime. The UI transaction may problably take several operations to complete (several request from a web application point of view), but in general transactions implementations use locks for concurrency control. So I cannot keep a transaction opened till the user finishes the operations from the UI (for example, he may want to create an object of the model, then add some items to some collection of that object, all in a transactional way). What's more, db transactions get restarted silently in case of concurrency issues (records read or write failures, deadlocks; this depends on concurrency control implementation) and the application cannot be aware of that. The consecuence is that the user may have performed operations based on some knowleadge that will not hold if the transaction gets restarted silently. For example, in the UI transaction, I may have done some query and present the results to the user for him to make a desision. Then the user goes on performing some operations and commits the transaction based in the results that were presented to him. As a result, the db transaction has a query and some updates as a result. When the db transaction commits, some concurrency related errors arise, so the db engine decides to restart it silently. But now, the query results are different as a consecuence of other user's changes, but the transaction still commits successfully. The application is not aware of that and the user is not warned of that (the new query results are never displayed again to the user). I think no db engines address these problems. Locking is not quite possible to have (we don't want users to be locked for so much time). So we need non-locking algorithms. I think the appropiate one would be some kind of optimistic algorithm. Changes are performed isolated without blocking anything. At the time of doing the commit, the transaction is validated. If it is not valid (some other user modified our transaction "memory"), then the application gets notified of that. The application is able to notify the user and provide mechanisms for recovering. The user could be presented with the new data, decide to goon with the commit, let the transaction restart silently till it is successful (he may not care about the result presented to him, he just wants his operations commited). The algorithm would be similar to the one used for STM [1]. It doesn't lock records and deadlock cannot occur. Progress cannot be guarranteed, though they claim it is unlikely to occur in practice. The difference would be in removing silent restarts. I hope I've been able to explain my problems successfully to you. I can reformulate them in case I haven't explained them clearly. On the other hand, I may be totally wrong. I've read magma uses optimistic locking, which is quite good. Don't know about transactions restarting. My questions are: 1) Does what I am saying make any sense? :) 2) How do you attack these problems in your applications? Sorry for the long mail and thanks for your time. Cheers, Mariano http://www.eureka-consulting.com.ar http://phpwebbuilder.sourceforge.net [1] Software Transactional Memory - http://research.microsoft.com/~simonpj/papers/stm/stm.pdf

2 2

Concurrently allocated sessions get into trouble
by Keith Hodges 26 Jun '07

26 Jun '07

Dear Chris, I discovered that opening a session, before a prior session had completed being opened resulted in two open repositorycontrollers. i.e. openedOn: was returning nil for a controller that was already in the process of being opened. This also results in clients being given the same id for multiple sessions. I solved this by putting a critical block around our #newSession code. Keith

3 2

can't add an index to a MagmaCollection which already has some elements
by Balázs Kósi 24 Jun '07

24 Jun '07

Hi, (MagmaCollection new) add: Object new; addIndex: (MaSearchStringIndex attribute: #printString); yourself results in an MNU: MagmaIndexDescription >> indexHashesFor: I think this worked in a previous magma version. We are now using Magma client-kph.243. Any thoughts? Cheers, Balazs

2 2

Transcript show in transaction ?
by Florian Minjat 21 Jun '07

21 Jun '07

Hi, I just found a Transcript show in the middle of MagmaSession>>becomeForward: which slows down a lot the transaction. This can't be normal I think. Florian

3 2

Object identity
by Florian Minjat 20 Jun '07

20 Jun '07

Hi, I am trying to transfer a big object hierarchy to Magma : 110100 objects in 9004144 bytes. The basic structure is composed of ~70 Players with a lot of stuff inside. Each players can have some Letters which references other Players as sender or recipients. The problem is that I can't submit one player to an empty Magma repository without letting Magma insert all the references Players. And the resulting transaction is too big, causing an error. So I separated all the Letters from the Players, inserted the players (~50min) and then tried to insert the Letters. But I close the connection to the magma repository between the two, so Magma tried again to load all the references Players. So here is my question : how does Magma identify a given object as already inside a repository ? Does it compare the hash of the objects and I just need to redefine the hash method of Players ? Each try is quite long so I would like to understand a little more of the inner mechanisms of Magma instead of trying numerous times. Florian

2 13

Re: [Setools] MagmaServerRequests
by Chris Muller 18 Jun '07

18 Jun '07

Ok, but what about the responses? On 6/17/07, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: > Chris Muller wrote: > >> I have made it fairly generic since it passes arbitrary messages, and > >> returns any values, trapping server-side errors, it transports them back > >> over the wire in order to signal them in the client. > > > > "Ma client server" does not support a dynamic protocol; only fixed > > which must be established just before session negotiation. How do you > > handle this? > My MagmaServerRequest being a subclass of RepositoryRequest is > registered as part of the Magma protocol as you say. It has an attribute > 'requests'. This is passed as an Array of Message' instances, both of > these appear to be understood by Magma for serialization. At the other > end I check that the Message-#selector's are defined in the > #requestsSupported and simply send them to the class that implements > that selector. > > cheers > > Keith > > _______________________________________________ > Setools mailing list > Setools(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/setools >

2 1

MagmaServerRequests
by Keith Hodges 17 Jun '07

17 Jun '07

Dear All, I have uploaded an add-on package to http://www.squeaksource.com/MagmaTester called 'Magma server requests'. This is as mentioned in a previous email to this list but it is now packaged in a generic form independent of Gjallar. to install with Installer use: Installer mc http: 'http://www.squeaksource.com'; project: 'MagmaTester'; install: 'Magma server requests'. After installing the package into a working Magma installation, you will need to do a MagmaSession cleanUp to get it adopted by the MagmaRepositoryController's I have made it fairly generic since it passes arbitrary messages, and returns any values, trapping server-side errors, it transports them back over the wire in order to signal them in the client. Actions are atomic since, and I quote from the "Magma client server" read-me text. "The answer block is only ever evaluated for one client request at a time." So to use this all you have to do is implement the Client side and the server side in MyOwnServerRequestResponder e.g. Client side: MyClass-counterValue ^ (self magmaSession serverRequest counterValue) submit e.g Server side MagmaRequestResponder subclass: MyOwnRequestResponder -- MyOwnRequestResponder-#counterValue ^ Count := Count + 1 -- RequestResponder-class-#requestsSupported ^ #( #counterValue ) -- You can send a batch of requests like so... (self magmaSession serverRequest counterIncrement; counterIncrement; counterIncrement; counterValue) submit -- Then there is a handy server backdoor! Normally each request in a batch of requests is sent to the responder which can handle each request. However if we enable requests to be chained, such that the next request is sent to the result of the previous request we can gain full remote control of the server. This is enabled by MagmaServerBackdoorResponder which in itself only serves one request: #login:password: e.g. ((self magmaSession serverRequest login: 'admin' password: 'magma rocks') repositoryController isReadOnly) submit To do: The login could be tied in to magma's exisitng users management. Some responders need simple persistence for their use which I do not know how to do enjoy Keith

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma June 2007