Hi all; One of the problems that can occur in concurrent use, especially with payment processing is that two users could indeed run the same payments, print duplicate checks, etc. This is a risk relating to paying vendors, and could be a means of embezzlement because a dublicate-looking check is printed without a record in the db.
SQL-Ledger 2.8.0 and higher solves this problem with a "semaphore" table which essentially provides locking capabilities through the appliction. This has been the source of a lot of problems in SQL-Ledger in part because of inherent problems in determining when a given lock should time out. I propose a different solution. Instead of having one master "lock" table, we add locking columns to affected tables. This field references the session id of the lock (with an on delete set null action). The session table will be expanded to include a timeout value in seconds. The first thing we do when we load a page is to delete stale sessions. Then we can just check locks for the rest of the time the page is loading. Any feedback would be appreciated. Best Wishes, Chris Travers ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel