|
Home > Archive > Commerce Server General > April 2005 > Optimistic locking
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Optimistic locking
|
|
| Obiwan Jacobi 2005-04-05, 5:51 pm |
| Hi,
As far as I can tell, there is no (optimistic) locking in CS2002SP3. We have
an e-commerce website and several order processing processes that all work
with (potentially) the same (order) data. Has anyone tried to implement
optimistic locking in CS? Or does anybody have any pointers (and why is this
not standard in CS2002!!)
--
Grtx
Marc Jacobi
| |
| Robert Bogue [MVP] 2005-04-06, 7:52 am |
| We single thread (or use a dispatcher model for) some operations to prevent
issues. You'll see similar problems if you try to do product catalog
updates.
--
MS MVP Commerce Server, MCSE, MCSA:Security, etc.
I'm speaking at SharePoint Advisor Live! June 12-16th. Goto
http://advisorevents.com/cmt0506p.nsf/w/main-cms for more details
"Obiwan Jacobi" <ObiwanJacobi@discussions.microsoft.com> wrote in message
news:FC46CABF-62AE-489C-AA01-1483EAF24F92@microsoft.com...
> Hi,
>
> As far as I can tell, there is no (optimistic) locking in CS2002SP3. We
> have
> an e-commerce website and several order processing processes that all work
> with (potentially) the same (order) data. Has anyone tried to implement
> optimistic locking in CS? Or does anybody have any pointers (and why is
> this
> not standard in CS2002!!)
> --
> Grtx
> Marc Jacobi
| |
| Obiwan Jacobi 2005-04-06, 5:54 pm |
| But thats so stupid! Every website has this issue (people pressing F5 and
issuing a second request for the same job)! -Oh sorry. No, you're workaround
is not stupid ;-)
The solution I'm currently working on involves a trigger on the OrderGroup
table that increments an version_seqnr (bigint) for the order being updated
after checking that the version_seqnr thats in the database is the same as
the version_seqnr being passed in the update. It will Raise an error and
rollback the transaction if these are not the same. Also after each save on
our Order we bump the version_seqnr in memory too (saves a trip to the
database). If the trigger raised an error this code will not be called.
Any thoughts on this solution, Robert? I'm not a big fan of triggers but in
this case it keeps the solution nicely transparent (except for that one code
change in our Save method)...
Thanx,
Marc Jacobi
Macaw Netherlands
"Robert Bogue [MVP]" wrote:
> We single thread (or use a dispatcher model for) some operations to prevent
> issues. You'll see similar problems if you try to do product catalog
> updates.
>
> --
> MS MVP Commerce Server, MCSE, MCSA:Security, etc.
> I'm speaking at SharePoint Advisor Live! June 12-16th. Goto
> http://advisorevents.com/cmt0506p.nsf/w/main-cms for more details
> "Obiwan Jacobi" <ObiwanJacobi@discussions.microsoft.com> wrote in message
> news:FC46CABF-62AE-489C-AA01-1483EAF24F92@microsoft.com...
>
>
>
| |
| Robert Bogue [MVP] 2005-04-13, 7:58 am |
| That's what the timestamp field is designed to do ... check for differences
in versions. But other than that, it is a solution. If it works for you it
seems reasonable.
Rob
--
MS MVP Commerce Server, MCSE, MCSA:Security, etc.
I'm speaking at SharePoint Advisor Live! June 12-16th. Goto
http://advisorevents.com/cmt0506p.nsf/w/main-cms for more details
"Obiwan Jacobi" <ObiwanJacobi@discussions.microsoft.com> wrote in message
news:32EDA0DA-2B83-4D75-A3FD-C8A09334FADB@microsoft.com...[vbcol=seagreen]
> But thats so stupid! Every website has this issue (people pressing F5 and
> issuing a second request for the same job)! -Oh sorry. No, you're
> workaround
> is not stupid ;-)
>
> The solution I'm currently working on involves a trigger on the OrderGroup
> table that increments an version_seqnr (bigint) for the order being
> updated
> after checking that the version_seqnr thats in the database is the same as
> the version_seqnr being passed in the update. It will Raise an error and
> rollback the transaction if these are not the same. Also after each save
> on
> our Order we bump the version_seqnr in memory too (saves a trip to the
> database). If the trigger raised an error this code will not be called.
>
> Any thoughts on this solution, Robert? I'm not a big fan of triggers but
> in
> this case it keeps the solution nicely transparent (except for that one
> code
> change in our Save method)...
>
> Thanx,
> Marc Jacobi
> Macaw Netherlands
>
> "Robert Bogue [MVP]" wrote:
>
|
|
|
|
|