T
Thomas Mercer-Hursh
Guest
There are a number of different issues floating around in here which I think are getting munged together at the expense of clarity. You talk about the expense of sending a lot of data to the client. The usual solution for that is to do the assembly on the AppServer and then only send a limited amount of data over the wire. Maybe I am old-fashioned, but I get a bit nervous around ideas like semi-persistent, although there architectures where one can do something like that safely. E.g., if one uses a distributed architecture with a tool like Sonic say Order Processing on one (or more) machines and Inventory on a different machine, then it can be useful to cache some inventory data on the OP machine to avoid excessive requests about the network. But, to do that one has to be careful in the design to commit anything that changes inventory to the inventory machine and, if possible, to provide Inventory with a signal that it can send to OP when some presumed relatively static information changes. I can't say that the idea of accessing data with SQL is an attractive alternative to ABL. Reconnecting to a prior session's TTs sounds like an EXTREMELY risky idea. How do you have any idea how current the data is?
Continue reading...
Continue reading...