Re: MVC Architecture and transactions

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?