jianming
Posts: 2
|
| Posted: 07/20/2004, 12:37 PM |
|
I am developing a phone card sale website.
It works like this: a user buys a phonecard. The system retrieves a pin number that is NOT marked as sold from database, and sends it to the user.
The concurrency issue is: if two users buy a phonecard at exactly the same time, the system will send the same pin number to them. So there should be a mechanism for exclusively locking the selected record.
With CCS 2, a recordset is opened like this:
Dim MyDB
Dim SQL
Dim RecordSet
Set MyDB = new clsDBconnDB
MyDB. open
SQL = "select pin_number from pin where sold = false;"
Set RecordSet = MyDB.execute(SQL)
In the above procedure, where can I specify the locking type of the recordset?
Thanks a lot.
Jianming
|
 |
 |
DonB
|
| Posted: 07/20/2004, 6:48 PM |
|
The underlying ADO Connection object (where you could call the BeginTrans,
CommitTrans or RollbackTrans methods) is "private" in the existing
connection class created by CCS. Why, I don't know.
However you could (a) create your own transaction methods and incorporate
them into the existing CCS connection class (in Common.asp).
OR
You could create an ADO connection (via CreateObject("ADODB.Connection", NOT
via "New clsDBconnDB") and use that to retrieve a pin number from within a
transaction executed against the ADODB connection.
--
DonB
logging at http://www.gotodon.com/ccbth, and blogging at
http://ccbth.gotodon.net
|
|
|
|
jianming
Posts: 2
|
| Posted: 07/21/2004, 9:57 AM |
|
Hi, DonB
Do you think transactions are necessary for solving concurrency issues? I am not sure.
I read Common.asp and plan to add to it a new class called clsDBConnection2, which has exactly the same definitions as clsDBConnection1 created by CCS. The only difference is that, in clsDBConnection2, I will set the RecordSet's locktype to adLockPessimistic.
I will use this new class where concurrency issues may arise. Do you think this will work?
Thanks.
|
|
|
|
DonB
|
| Posted: 07/22/2004, 6:31 PM |
|
Surely were talking about a read followed by a write - selecting the next
pin and assigning it to someone.
Yes, a transaction is necessary to guarantee you don't have a second reader
pull the same pin number before the first one gets it marked as sold.
Pessimistic locking only locks the record during the interval in which the
record is in "update" mode (from the .Edit/.AddNew until the .Update), so it
would be possible to have two readers (with no locking) prior to one writing
(at which time the lock is active and both readers and writers would be
blocked). Optimistic locking would only lock the record at the moment the
..Update is executed.
--
DonB
logging at http://www.gotodon.com/ccbth, and blogging at
http://ccbth.gotodon.net
"jianming" <jianming@forum.codecharge> wrote in message
news:640fea06e9f987@news.codecharge.com...
> Hi, DonB
>
> Do you think transactions are necessary for solving concurrency issues? I
am
> not sure.
>
> I read Common.asp and plan to add to it a new class called
clsDBConnection2,
> which has exactly the same definitions as clsDBConnection1 created by CCS.
The
> only difference is that, in clsDBConnection2, I will set the RecordSet's
> locktype to adLockPessimistic.
>
> I will use this new class where concurrency issues may arise. Do you think
this
> will work?
>
> Thanks.
> ---------------------------------------
> Sent from YesSoftware forum
> http://forums.codecharge.com/
>
|
|
|
|
|
