Locking, neasted ECs and Cocoa/EO

Ricardo Strausz <[email protected]> Wed, 21 Jan 2004 18:32:13 -0600
Newsgroups gmane.comp.web.webobjects.eof,gmane.comp.web.webobjects.devel
Message-ID <[email protected]>
Hola tod@s!

You may give me a voice of advice on the following isues:

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