Locking (neasted ECs and Cocoa/EO)
Locking (neasted ECs and Cocoa/EO)
- Subject: Locking (neasted ECs and Cocoa/EO)
- From: Ricardo Strausz <email@hidden>
- Date: Wed, 21 Jan 2004 14:16:05 -0600
Hola tod@s!
For the last days, there has been a deep disscution on Locking, so you
may give me a voice of advice on the following isue:
The Model (simplified):
Clients <-->> Invoices <-->> InvoicesItems
||
Clients <-->> CreditNotes <-->> CreditNotesItems
The Goal (again, simplified):
The Invoices.app will create/insert new invoices and, when done, will
modify/update the balance of it related client by adding the amount of
the invoice (which is in fact the sum of the invoiceItems).
First cuestion:
Shall I use a neasted EC for the Items? If so, How?? (the primary key
of an invoice (folio) have to be part of the compound key of its items
(folio, itemNo), so, I think, the invoiceItems have to be saved after
the invoice).
---I know, the ideal thing is to have meaningless-PKs, but this squema
is running and cannot be changed (at least in the short term).
On the other hand (the goal, continued):
The CreditNotes.app will create creditNotes and when done, will modify
the balance of it related client by substracting its amount.
The Problem:
These apps are running concurrently in different machines, so they can
try to modify a client at the same time with the possible
inconsitencies (especialy if we use "not locking" ---or as called by
Chuck: "naive locking"). Also, a simple panel saying "cannot save" is
not enough; the document (invoice or creditNote) HAS to be saved and
its client.balance HAS to be correctly modified.
An Old solution:
In the old/good times of EOF 1.0, it was possible to go down in the
hierarchy of the framework and do the so-called "insert-loop" by hand,
previously starting a db-transaction, and doing pessimistic-locking
when required. This was my approach to the problem in that time (may be
not the best, but it worked).
Now, I am not sure what is the best thing to do ---EOF has evolving
VERY much, much faster than I can follow, so I hope there is a better
approach... at least easer to implement.
Finally:
To add more interest to the isue, this apps are being done in
Cocoa/EOF, so there is not a unique server taking care of all
users/clients, they are independent apps each running in its
space/time, but, of course, they have access to the same db.
I will realy apreciate any insight in these two isues.
Sincerly yours
Dino
p.s., Chuck: you should add these topics in you book (if they are not
already there)... had you think in adding something about Cocoa/EO??
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.