In my multi-user application, i have a button 'modify' to update an entity fields. I want to control entity access with llblgen concurrency control of kind so that just one user can modify the entity, a second one will be blocked immediately after clicking on the 'Modify' button.

Please check Concurrency control in the LLBLGen Pro manaual's section "Using the g enerated code -> SelfServicing/Adapter -> Using the entity classes"

I have read the documentation, but no answer to my question :s I generate the business object in selfServicing mode, and i want to lock an entity not while save or delete it, but while the "modify" button is pressed (im locking for having the same record locking in databases)

Then you should use an (open) adapter/connection which is in a specific isolation mode as long as you're editing the entity....I guess.

grtz, Danny

I think what you want to do is very tricky. On what condition should the modify button be disabled for a user?

Anyway I think a call to the database shoulod be made to detect if the entity was updated or checked-out (flag) to be modified. And while this check may pass when the user fetches the entity, it may fail when he attempts to update the entity. (the entity state might get changed between him fetching the entity and saving it). So anyway a database check upon attempting to save is crucial.

The only way to do this properly is to use 'feature/functionality locking'. This means: one user starts an edit on an entity E, and by doing that, it stores a value in a locking table for editing E. All other users will then not be able to edit E. This is common in CMS's for example: one user enters the edit of a page, all other users can't edit the page, it's locked by the user.

Database locks aren't the way to do this, that will severily hurt performance as the lock is upheld during a user action (which can take all day). See: http://weblogs.asp.net/fbouma/archive/2003/05/24/7499.aspx for all the details.

Ok, agree...but what if the user's computer editing E crashes while editing.....then the lock-record is still there....and can be there all day. How to cope with that ?

That's like source safe check-out and check-In functionality. And the user may check out a record and keep it checked out for as long as he can.And if the applications crashes, he shuold be able to re-open it and unlock or commit which ever record he is holding. Since locking is maintained in the database not in memory, this should not be a problem at all.

You can have a preset time-out value that would prompt the locking user to confirm he still want to keep editing or his lock will be released. You can then create a system wide admin task for the app admin to clear all timed-out locks in batch-mode manner.

Thanks a lot for answers, i will try and keep you informed

Using the CMS example again, I've seen some that automatically clear all exclusive locks on login or after browsing another page. This would help in those cases where the user's computer crashes and they login again, giving the CMS a chance to realize that the user is no longer editing a page.

Using the CMS example again, I've seen some that automatically clear all exclusive locks on login or after browsing another page. This would help in those cases where the user's computer crashes and they login again, giving the CMS a chance to realize that the user is no longer editing a page.

Great tip !!