Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
"Transaction Processing" using ASP/SQL Server
#1
Do some of you guys know what I mean by Transaction Processing? It's a facility to prevent partial updates when your system aborts or crashes.

Example: Let's say I get input from the user and then need to write parts of this input data to two files. I can't allow the write to the first file to happen alone without also the write to the second file. On many systems that support Transaction Processing, you would do it like this:
1) Get the input data.
2) BEGIN TRANSACTION.
3) Write data to file number 1.
4) Write data to file number 2.
5) END TRANSACTION.
6) Send acknowledgement of updates response to the user.

If there was any system problem between the BEGIN and END transaction statements, neither file would be written to.

This is not something I dreamed up, this is a common error handling solution offered by many operating systems and datbase management systems.

Ok, now to the question. How can I do this kind of thing from web-based programs using ASP and SQL Server? When I ask the web programmers, first they never even heard of Transaction Processing, and then they look at me like I'm crazy.
*****
Reply
#2
This is something we've studied and that we call "semáforos". Sorry, appart from that I can't help you with ASP... This message went only to say "no, no estás loco" Wink
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
#3
I'm sure ASP with SQL server can do transactioned stuff... if you can find a copy of the IIS Resource Kit ( a book from MS press with CDs) it talks about transactions a lot. I couldn't give you a code example off the top of my head, tho.
Reply
#4
I don't know anything about SP, except that it's supposed to be M$'s competition to PHP. In the ASP, store all of the data in variables before adding them to your DB, so everything is written to SQL at once. I highly doubt the server would crash right in between the split second it takes to update a DB. The only thing you have to watch out for then, is your SQL handling (don't make any mistakes when you are writing the SQL instruction).

So... I know nothing about transaction processing... I'd just wait for DrV, since mine is a made-up solution.
ammit potato!
Reply
#5
If you're interfacing with postgreSQL, you can create a transaction by adding BEGIN; and COMMIT; to your sql, but I don't know how that would work for creating files...

It's best to use databases, especially postgres, cos they're designed to store data securily (sp?), but I know nothing of asp and nothing of file transactions...
Reply
#6
Thanks for your thoughts, guys.

The issue of transaction processing is nothing new. What's new is that nowadays, even those that understand the implications, don't really care. The few that care can't get management to spend the extra money for the additional software required at the operating system or database manager level.

Another critical issue in a multiuser environment is the need to do READ-WITH-LOCK or READ-FOR-UPDATE when you read a record that you are going to update and write back to the file or database. This avoids two asynchronous processes (programs) from erroneously updating the same record at the same time. Nobody seems to bother considering this any more.

This is a trend that I see happening since businesses began converting their systems to run in a web-based environment, either Internet or Intranet. Many long-honored, traditional standards of the computer industry, that I've personally seen evolve in the last 40 years, are being ignored or forgotten. Many of these standards still need to be programmed, that is, they are not automatically built in to the OS, DB managers or languages.

What's going to happen to the quality of systems when the new programmers are no longer aware of these standards? It makes me sad to think about it.
*****
Reply
#7
The text-based (unofficial) hitcounter on QBNZ makes use of file locking... and databases lock stuff anyways (well, at least you can with postgres...)
Reply
#8
Thanks, Oracle. I'm glad that QBNZ locks records for update.

Yes, I'm sure all database managers have the facility, but it's not automatic (you don't want to lock inqury-only reads), you have to program for it. However, do the programmers know about it or bother to do it? My recent experience has shown that programmers very often do not make use of the facility, for one reason or the other.
*****
Reply
#9
Oh man, Moneo. You should see the database class I took. You'll worry no more. At least for the ones who survived...
Peace cannot be obtained without war. Why? If there is already peace, it is unnecessary for war. If there is no peace, there is already war."

Visit www.neobasic.net to see rubbish in all its finest.
Reply
#10
Good, Aga, I'm glad the fundamentals are still being taught. Too bad many of today's programmers never were able to take these courses, and as a result they program by the seat of their pants.
*****
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)