[ANN] Tantalus

Colin Putney cputney at whistler.net
Mon Aug 19 22:45:01 UTC 2002


On Monday, August 19, 2002, at 04:34  AM, Jon Hylands wrote:

> I have a couple comments. You say in the documentation "The objects
> inserted must not contain circular refrences" yet your example objects 
> (in
> the documentation) have a circular reference in the relationship between
> ABPerson and ABTelephoneNumber, and presumably when you send
> #addTelephoneNumber: to the person it sets this up. How does this work?

Oops, that should be "circular relationships."

There's only one relationship between ABPerson and ABTelephoneNumber, 
the one that uses tPersonID. The relationship can be traversed in both 
directions: given a person you can find all her telephone numbers and 
given a number you can find out what person it belongs to. When you've 
got the objects in memory, they do, of course, contain references to 
each other.

Circular relationships would be where you have a second relationship in 
ABTelephoneNumber that led you back to the same ABPerson. Say you added 
a 'receptionist' instance variable to ABTelephoneNumber, the person who 
actually picks up the phone when you call the number. If a telephone 
number had the same ABPerson as 'person' and 'receptionist' you'd have 
circular relationships.

> Since you don't seem to have any form or support for transactions, how 
> can
> you possibly handle mutliple users? Atomic inserts and updates of 
> multiple
> objects from a single user are a cornerstone of relational database
> integrity. Its a problem you don't want the application to have to deal
> with -- that's what database frameworks are for.

Dang, that part seems to be missing from the documentation. Tantalus 
does support transactions, it just implements them internally rather 
than using transactions in the database.

There are three things you can do to modify the database: inserts, 
deletes and updates. You do inserts and deletes explicitly, by calling 
TNEditingContext>>insert: and TNEditingContext>>delete:. Updates are 
implicit, when you modify the instance variables of your entities you 
schedule an update.

None of these operations take place until you call 
TNEditingContext>>commit. If you change your mind, you can call 
TNEditingContext>>abort, which will abandon all scheduled inserts and 
deletes and revert your entities to the state they were in when they 
were retrieved from the database.

> And finally, are you familiar with GLORP? How does Tantalus compare with
> GLORP, and why would I want to use it instead?

Yes, I am aware of GLORP, though I've never used it.

The difference between Tantalus and GLORP is the strategy used to ensure 
the integrity of the database. GLORP uses database transactions; 
Tantalus uses atomic updates. Here's an example of how an atomic update 
would work:

Say you change Joe Jackson's phone number and commit. The SQL Tantalus 
generates would look something like this:

UPDATE telephoneNumber
	SET tNumber='604-655-8953'
	WHERE tID=1343 AND tNumber='901-655-8953'

After the update Tantalus checks the number of rows that were affected. 
If one row was affected, the update was successful and everything is 
fine. If no rows were affected, then some other user has changed the 
number while we weren't looking. Tantalus will throw a TNCommitConflict 
error so the application can decide what to do.

There's a discussion of atomic operations in MySQL here:

http://www.mysql.com/doc/en/ANSI_diff_Transactions.html#IDX148

Atomic operations is a lighter-weight model than transactions, so it 
usually offers better performance and concurrency. If this is what 
you're after Tantalus might be a better solution for you than GLORP.

To be completely honest, I don't expect to see a lot of Tantalus users. 
Not using transactions is fairly unorthodox in the database world, and 
not many people will even consider it. But hey, it scratches my itch, 
and maybe somebody else will find it useful as well.


Colin Putney
Whistler.com




More information about the Squeak-dev mailing list