cancel
Showing results for 
Search instead for 
Did you mean: 

Dealing with concurrency when accessing BO

Former Member
0 Kudos
92

Hi,

I'm currently facing the following problem. I have kind of a "singleton" BO which manages number ranges for BOs. The generation of new IDs happens in the "before save" action of the respective BO. Now assuming two BOs are saved at the same time (by different users) they both can get the same ID. Does anybody know how I can aquire somthing like a lock while saving until the save transaction is completed?

- Daniel

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Anreas,

thanks a lot. With your help I managed it to work now, though the actual solution differs a bit.

Just as an info we are working with FP3.0.

As you proposed I implemented a locking test. However, step 3 (calling a ruby script with $controller.ErrorOccured) was not necessary, as the call to the locking test already raised an error if the number range manager was locked. So any subsequent calls (e.g., a call to the method that causes the ID generation and the save event) were not executed.

Kind regards,

Daniel

Former Member
0 Kudos

Hi Andreas,

if I get you right, that's almost the way I've already done it. To put things straight I'd like to explain the status quo a bit more detailed.

I have a BO NumberRangeManager (for this BO only one instance exists). It generates new IDs and holds the last generated one. That is, when saving a new instance of another BO (e.g., MyBO) I retrieve the "Singleton" BO NumberRangeManager in the BeforeSave Event and call the action "GenerateID" (this action belongs to the NumberRangeManager). The action generates the new ID and allocates a dedicated field with the new ID. I have no clue how to explicitly call a save on the NumberRangeManager from an action (ABSL).

Thus, it seems when two BO instances of MyBO retriev the NumberRangeManager they each get a copy of the NumberRangeManager. The call to "GenerateID" then results in the same new ID for both instance, as each copy of the NumberRangeManager does not see the newly generated ID of the other copy.

I hope I did clarify things more than confused them. It's really complicated to describe the issue in a comprehensible way.

Regards,

Daniel

Former Member
0 Kudos

Hi Daniel,

ok, I know the problem of locking in ByDesign...you could try the following steps:

1. Before you execute the save operation, you execute a new action "LockingTest" (UI-Designer event handler entry)

2. In this action you manipulate a value in your singelton BO, e.g.:

Singelton.value1 = Singelton.value2

3. After that you can check in UI-Designer if an error is occured ($controller.ErrorOccured) (ruby script in event handler)

4. If you get no error, the business object is locked for you (otherwise it is locked by another user/BO)

I had to check it in a seperate window (modal dialog)...was in FP2.6...I don`t know if it now works in same window...

5. now you can generate and set a new ID

6. save your BO (singelton BO will automatically saved as well)

7. Now your singelton is unlocked again

Save operations always depend on your current UI screen. Only if you save in UI, changes will be written back in database and only if you execute a action and come back to UI, you can lock BOs (FP2.6, FP3.0?).

I used similar steps for one of my developments...not very elegant but it worked for me. Currently, I can not access my old UI code (solution in in maintance mode) but I think I can do it again next week...so if you have further question...

I hope it works for you too...

Regards,

Andreas

Former Member
0 Kudos

Hi Daniel,

what is if you create a second BO that delivers you IDs?

You retrieve this second BO in BeforeSave event of respective BO and it creates you an ID (you execute a action of the second BO). In this action the second BO creates an ID and saves it. While creating and saving the last ID in second BO, the BO is locked and you will get an unique ID.

Regards,

Andreas