Re: MVC Architecture and transactions

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hmmm... I read an entire transaction into memory at once using some sort 
of a "load" procedure (using arrays, data structures, and dynamic 
allocations where necessary.)  I save it back to disk all at once using 
some sort of a "save" procedure.

I use dynamically allocated memory, and pass the pointer as a "handle" 
to the caller, so the caller can potentially have multiple transactions 
(usually orders, POs, invoices, etc) loaded into memory at once.  Or 
there can be multiple callers.

I don't like to hold record locks or use commitment control, etc, 
because it interferes with the "statelessness" of my Model, requiring me 
 to call certain procedures in a certain order -- and I've always tried 
to avoid that as much as possible.  It also interferes with my ability 
to process multiple transactions at once.

However, I'm NOT sure that the way I do things is the best way.  It's 
rather complicated, and involves a lot of pointer logic -- which some 
people don't like for some reason.  Plus there's still a chance (however 
small) that a partial transaction could be written if there's some sort 
of failure.

So I kept out of this discussion, figuring who wants the advice of 
someone who doesn't really know what's best?

Wilt, Charles wrote:
> Really thought this question would get more responses...is everybody
> to busy fighting over the cycle?
>
> Scott, Aaron, Joe, Alan, Jon, et. al.  Any thoughts guys?