PDA

View Full Version : Record Locking در SDAC


MNosouhi
سه شنبه 16 بهمن 1386, 10:11 صبح
با سلام
دوستانی که از sdac برای برنامه نویسی تحت شبکه استفاده می کنند ، میشه توضیح بدن مسئله همزمانی رو چطور حل کرده اند (به عنوان مثال زمانی که چند کلاینت همزمان سعی در ویرایش یک رکورد می کنند)؟
Mahyaa
سه شنبه 16 بهمن 1386, 13:19 عصر
من از SDAC لستفاده نکردم . ODAC رو استفاده کردم که قفل کردن رکورد و کلا مسائل مربوط به ویرایش همزمان رکورد ، مشابه با کنترلهای مربط به ADO هستش . تفاوت خاصی نمیکنه .
vcldeveloper
چهارشنبه 17 بهمن 1386, 02:20 صبح
بصورت پیش فرض از Optimistic استفاده میکنه و در هنگام آپدیت هم فقط مقدار فیلدهایی که تغییر کردند و فیلدهای Key رو منتقل میکنه، غیر از اینکه مقدار UpdateAllFields در خصوصیت Options برابر True باشه.
اگر بخواید از Pessimistic استفاده کنید، باید مقدار CheckRowVersion و DMLRefresh را True کنید. در اینصورت، اگر رکورد توسط کاربر دیگه ایی تغییر کرده باشه، یک پیغام خطا دریافت می کنید. دقت کنید که این روش در صورتی که در لیست فیلدها فیلدی از نوع Text داشته باشید، جواب نمیده. این یک باگ هست که گفتند در ورژن آینده برطرف می کنند.
برای Pessimistic یک روش دیگه هم اینجا هست که من آزمایش نکردم، ولی جالبه:
http://www.crlab.com/forums/viewtopic.php?p=8301&sid=6f6ac1843a14974a8980f50f4873541f

اگر هم چند رکورد را با هم Update می کنید، یعنی از ApplyUpdates استفاده می کنید، اون وقت می تونید از رویداد OnUpdateError برای مدیریت خطاهای ایجاد شده در هر رکورد استفاده کنید و مشخص کنید در صورت بروز خطا چه عکس العملی باید انجام بشه.
MNosouhi
شنبه 20 بهمن 1386, 06:50 صبح
با سلام
مطابق عرایض شما عمل کردم ، اما نتونستم قفل Pessimistic رو پیاده سازی کنم :
vcldeveloper
شنبه 20 بهمن 1386, 15:05 عصر
نتونستم قفل Pessimistic رو پیاده سازی کنم
مثال شما را آزمایش کردم، بدون مشکل Pessimistic را پیاده سازی کرد. در هنگام ثبت تغییرات رکورد توسط کاربر دوم خطای Found 0 records به درستی ایجاد شد و نمایش داده شد.
MNosouhi
یک شنبه 21 بهمن 1386, 06:38 صبح
مثال شما را آزمایش کردم، بدون مشکل Pessimistic را پیاده سازی کرد. در هنگام ثبت تغییرات رکورد توسط کاربر دوم خطای Found 0 records به درستی ایجاد شد و نمایش داده شد.
شاید تصور من از قفل خوشبینانه و بدبینانه اشتباهه .
اما تا اونجایی که یادمه در Optimistic ، به هنگام ذخیره سازی اطلاعات ، اگر کاربر دیگری تغییراتی ایحاد کرده بود پیغام خطایی میداد .
و در Pessimistic اصلا اجازه نمیداد که یک رکورد به صورت همزمان توسط بیشتر از یک کاربر در مد ویرایش قرار بگیرد.
حداقل در dbisam که اینطوریه.
vcldeveloper
یک شنبه 21 بهمن 1386, 08:19 صبح
اما تا اونجایی که یادمه در Optimistic ، به هنگام ذخیره سازی اطلاعات ، اگر کاربر دیگری تغییراتی ایحاد کرده بود پیغام خطایی میداد .
و در Pessimistic اصلا اجازه نمیداد که یک رکورد به صورت همزمان توسط بیشتر از یک کاربر در مد ویرایش قرار بگیرد.
حداقل در dbisam که اینطوریه.
در Optimistic هر کی آخرین ویرایش را انجام داد، ویرایشش ثبت میشه. اما در Pessimistic اگر محتوی فیلد توسط کاربر دیگه ایی تغییر کرده باشه، به کاربر دوم پیغام خطا داده میشه و تغییرات وی ثبت نمیشه. کاربر دوم تا جدول رو Refresh نکنه، تا تغییرات کاربر اول اعمال بشه، حق تغییر محتوی فیلد رو نداره.
MNosouhi
یک شنبه 21 بهمن 1386, 11:00 صبح
در Optimistic هر کی آخرین ویرایش را انجام داد، ویرایشش ثبت میشه. اما در Pessimistic اگر محتوی فیلد توسط کاربر دیگه ایی تغییر کرده باشه، به کاربر دوم پیغام خطا داده میشه و تغییرات وی ثبت نمیشه. کاربر دوم تا جدول رو Refresh نکنه، تا تغییرات کاربر اول اعمال بشه، حق تغییر محتوی فیلد رو نداره.
حالا من میخام که اگر رکوردی در مد ویرایش بود و یوزر دیگری هم سعی در قرار دادن همان رکورد در مد ویرایش کرد یوزر دوم پیغام خطا دریافت کنه ( یعنی یک رکورد نتونه همزمان در حالت ویرایش قرار بگیره)
vcldeveloper
یک شنبه 21 بهمن 1386, 23:28 عصر
حالا من میخام که اگر رکوردی در مد ویرایش بود و یوزر دیگری هم سعی در قرار دادن همان رکورد در مد ویرایش کرد یوزر دوم پیغام خطا دریافت کنه ( یعنی یک رکورد نتونه همزمان در حالت ویرایش قرار بگیره)
سرور که از حال کلاینت ها با خبر نیست. وقتی یک رکورد در حالت ویرایش قرار میگیره، چیزی برای سرور فرستاده نمیشه که سرور جلوی این کار رو بگیره. وقتی تغییرات Post میشه، تازه سرور متوجه میشه که یک رکورد ویرایش شده.
اگر اصرار دارید که همچین رفتاری در سمت کلاینت صورت بگیره، می تونید کدی که در لینک بالا (لینک به فوروم Crlab) گذاشتم را در رویداد BeforeEdit از DataSet بذارید. در این حالت قبل از هر Edit کلاینت به سرور متصل میشه و چک میکنه که آیا رکورد مربوطه قفل هست یا نه. البته مطمئن نیستم که این روش هم جواب بده.
MNosouhi
دوشنبه 22 بهمن 1386, 00:10 صبح
با تشکر از جواب های شما .
شما خودتون در برنامه های تحت شبکه از چه روشی استفاده می کنید؟ با مشکلات همزمانی چگونه کنار آمده اید؟
vcldeveloper
دوشنبه 22 بهمن 1386, 01:05 صبح
شما خودتون در برنامه های تحت شبکه از چه روشی استفاده می کنید؟ با مشکلات همزمانی چگونه کنار آمده اید؟
من معمولا از Optimistic استفاده می کنم. اگر هم لازم بوده که از Pessimistic استفاده کنم، از همین مکانیزم موجود راضی بودم.
MNosouhi
چهارشنبه 24 بهمن 1386, 16:07 عصر
استفاده از CheckRowVersin و DMLRefresh تا زمانی موثره که خاصیت SQlUpdate از TMSQuery مقداری نگرفته باشه ، اگر مقدار گرفته باشه ، قفل Pessimistic عمل نمیکنه و هیچ پیغامی نمایش داده نمیشه ، با این مشکل چطور کنار آمده اید؟
البته سوال در فروم سایت Corlab هم مطرح شده :
http://crlab.com/forums/viewtopic.php?t=11523&sid=8694f937012d7e349f08cf0cd264feeb
vcldeveloper
پنج شنبه 25 بهمن 1386, 03:57 صبح
استفاده از CheckRowVersin و DMLRefresh تا زمانی موثره که خاصیت SQlUpdate از TMSQuery مقداری نگرفته باشه ، اگر مقدار گرفته باشه ، قفل Pessimistic عمل نمیکنه و هیچ پیغامی نمایش داده نمیشه
خب این طبیعی دیگه. وقتی از SQLUpdate استفاده می کنید، یعنی خودتون دارید کنترل کار رو بدست می گیرید، پس اینجا دیگه اون امکانات خودکار کاربردی ندارند، بلکه خودتون باید با کدنویسی یا دستورات SQL شرایط مورد نظر خودتون رو بوجود بیارید.
powerware
دوشنبه 20 اسفند 1386, 10:52 صبح
با عرض سلام
سوالی که همیشه برای من وجود داره اینه که چرا همیشه در برنامه نویسی کلاینتها رو مستقیما به sql server ارتباط میدند. آیا بهتر نیست بجای اینکار از یک application server به عنوان واسط بین کلاینتها و sql server استفاده نمود تا بتوان کلیه چکهای لازم (بعنوان مثال همین مورد اشاره شده در این تاپیک) را انجام داد؟
vcldeveloper
دوشنبه 20 اسفند 1386, 15:20 عصر
سوالی که همیشه برای من وجود داره اینه که چرا همیشه در برنامه نویسی کلاینتها رو مستقیما به sql server ارتباط میدند. آیا بهتر نیست بجای اینکار از یک application server به عنوان واسط بین کلاینتها و sql server استفاده نمود تا بتوان کلیه چکهای لازم (بعنوان مثال همین مورد اشاره شده در این تاپیک) را انجام داد؟
بستگی به معماری برنامه داره. اینطور نیست که همیشه کلاینت را به بانک اطلاعاتی متصل کنند!
مورد مربوط به این تاپیک باید در سطح بانک اطلاعاتی انجام بشه. چون حتی Application Server هم برای بررسی اینکه آیا رکوردی Lock هست یا نه باید به سرور بانک اطلاعاتی مراجعه کنه.
powerware
دوشنبه 05 فروردین 1387, 11:11 صبح
با عرض سلام مجدد
منظور این بود که اگر در application server شما لیست کلیه lockها را داشته باشید چون در این حالت کلیه ارتباطات با دیتابیس از طریق application server انجام میشه اگر بطور مثال یک کاربر در حال ویرایش یک رکورد باشه دیگه سرور به کلاینت دیگه اصلا اجازه ویرایش یا حذف اون رکورد رو نمیده.