Stored procedures vs. transactions (TP monitors)
Posted in 1993
Topics: High Availability & Replication, Stored Procedures & SPL
Before Informix v5.1 and Oracle v7 were available then there were two ways to implement complicated transactions (for example 'withdrawal', 'account status' and such): 1) Write the logic in the client program. (Lots of SQL flying back and forth over the network). 2) Buy a transaction monitor and write the logic as a transaction which the client executes remotly. Today, you can write this stuff as a stored procedure and it will work exactly (?) as a transaction did in the 'old days'. If you have a lot of clients (200-300 PC's) which will be running transactions all day and there isn't a great need for SQL access then which way is the best to go ? Use stored procedures or use a TP monitor ? What is the 'load' on the server in each case ? Is it faster to send transaction than to run stored procedures ? How much memory does each method use in the client (These are PC's running MS-DOS) If the answer is that stored procedures will be a better choise, isn't the TP monitor then a relic of the past ? Why should you spend a lot of money on something which you have anyway with your RDBMS ? If anyone has some experience with a TP monitor and a RDBMS which has stored procedures and is willing to shed some light on this matter, then please post or send e-mail to me. Thanks Steinthor -- Steinthor Bjarnason | ICEUUG chairman | This space available for Islandsbanki h.f. | Internet: stb@isbank.is | rent..... Kringlan 7 | Tel: +354-1-608000 | 155 Reykjavik, Iceland | Fax: +354-1-678711 |