Do you experience object could not locked error

[Former Member]

one of my customer asked me follwong question

from time to time when module booking is heavy got following message "object coult not locked'

and when i check module booking function, it is happening while function trying to create ST-E relationship.

here is my question, do you also have this message and how do you handle it ?.

your reqponse would be appreciated.

[dirk_pape3]

Hi Song,

is your question regarding standard module booking (studentfile), self service or even mass booking?

To establish the module booking the application surely needs to acquire logs for every object for which a relation must be written. These are ST, SM and if you have events: E/EL.

In each of the forementioned processes the user should receive a message, if the lock could not be established and hence the module could not be booked.

I think then the only way is to try again later, when the objects became dequeued.

Dirk

[michael_hobbins]

Hi Song: we've been having this error for many years. We have records of this error since 2008 (unfortunately we can't find previous records to check if this happened before). This has happened exclusively with bookings students do via web (our web app is developed by us, we're not using the selfservice provided by SAP, nor Portal). We haven't been able to solve it. It only happens when we have a lot of students booking courses at the same time.

The error we get is:

   Cannot lock object 01 E 00516646 [EHRPIQ000168]

   Internal error while booking to E 00516646 [EHRPIQ000814]

00516646 is the business event the student is trying to book to.

On Octobre 2008 we migrated from ERP 4.7 to 6.00, and on last February we migrated from 6.00 to 6.07. After migrating to 6.07 we haven't had any massive bookings so we can't know for sure if the problem persists.

On our records we found 4 of these errors before migrating to from 4.7, so this isn't exclusively for ERP 6.00.

We haven't been able to dig into the problem due to 2 reasons:

1. the error appears to quite a small amount of students (so we proceed as Dirk mentioned)

2. we don't have to tools te replicate stress situations.

Any other info you can add to see if we can solve this?

Michael

[Former Member]

I talked with Basis consultant and he recommend to increase "enque/table_size" and it will helpful in avoiding object lock error.

[michael_hobbins]

Hi Song,

   at the recent HERUG meeting, our friends from Duoc UC (Chile) told us they had this same problem and were able to solve it. The steps they did were (and we just copied):

Access Tx SPRO and open options as on the following image

and for the group MODREG, setting NO_SM_CAPA, you should have an empty value. Change it to "X"

Please read the documentation on the SPRO entry before any changes.

We will be opening web bookings in 2 weeks for masive access, we expect this to end with the error.

It this works, credits are for Manuel Salinas, Luis Tricot, Patricio Marchant and Rodrigo Garbarino.

Cheers,

Michaelq

[Former Member]

Dear Colleagues,

I find out this error occuring at E level and where there are lots of module booking.

Normally in our case module booking finished in a 5 minites for 3,000 - 10,000 students

for some specific module.

[Former Member]

Hi Michael,

I happened upon this post because my organization is also experiencing problems with errors creating locks on E objects.  We tried disabling the capacity check at the SM level as indicated above but it didn't seem to affect the issue.  Did this end up working for your mass booking and/or have you folks tried anything else?

Thanks!

Joshua

[michael_hobbins]

Hi Joshua: unfortunately not. No changes at all. We managed some stress test booking activity early June and still got the error. During late June we opened massive booking for students and we had the error appearing again when there's lots of students trying to book at the same time. Once the "attack" ends there's no block at all. We're really puzzled. Part of the team wants to create a message to SAP to see into this, but as this all inhouse development, I'm sure they will answer this is not an error and we'll hace to ask (and pay) for a consultant.

I'll come back to you if we manage to find a solution.

Cheers,

Michael

[Former Member]

Thanks for the reply Michael.  We are currently looking into something we hope will help. I don't have much detail at the moment but in case it is helpful, i'll give you a brief description as I understand it:

Yesterday, our SLCM folks found that, after the event lock is performed, the call to update the table (apparently a core function called RH_UPDATE_DATABASE) does an enqueue on another standard table called LSOCRPCNTXTSTAGE (LSO Correspondence Staging Area table). This enqueue call specifies a parameter which appears to make the call wait until a successful enqueue on the LSOCRPCNTXTSTAGE table can be performed.  Our HR department does use this functionality but our SLCM functionality does not need this.  Our web application logs indicate many requests that take much longer than the 2-6 second average time (30 - 140 seconds or so) and the call to enqueue the LSO table taking a long time corresponds with the longer booking transactions that we have looked into. Everyone who tries to book the same event as the person whose request is taking a long time will see the lock error.

Currently, we are trying to reproduce the issue and examine this closer in a development/test environment. If not waiting for a lock on the LSO table for bookings isn't found to be a problem and there is no configuration item specific to SLCM that we can change, we may have to use an enhancement point to make this 'wait' parameter wait for HR applications and not wait for SLCM applications.

We do have an incident with SAP and are adding details to it as we can.  We are hoping to investigate this avenue in advance of some booking activity next Tuesday.  I'll be sure to follow up with anything else we find as well.

EDIT:

After further review, it isn't waiting for the enqueue that seems to be the issue.  The code, however, that runs while dealing with this table is still suspect in our situation.  We have written an enhancement point to exclude this code when this update table command is run by booking or PIQST10 and are testing this change.  Initial results look promising but we hesitate to get too excited until we see things running in the production environment.  I'll follow up again soon.

Thanks!

Joshua

[Former Member]

All,

We did find that bypassing this LSO-related functionality for SLCM bookings drastically reduced the number of lock-related errors and average response time.  Our enhancement point was added to method IF_LSO_CRP_QUEUE_MANAGER~ADD_CONTEXT of the CL_LSO_CRP_QUEUE_STAGE_MANAGER object.  The enhancement point checks to see if the caller is either the PIQST10 GUI transaction or a Z_CM_STUDENT_BOOKING RFC call (RFC called by the web application to perform bookings).  If so, it exits the method immediately.

A session that historically would have produced around 600 lock-related errors in the first 12 minutes of registration activity instead caused around 50 lock-related errors instead and another the following day saw only 17 lock-related errors. 

Further, average response times are down from 7 seconds to 2 seconds and the maximum response time is down from 150+ seconds to 15 seconds.  With average response time down, we decided to automatically retry add/drop booking requests in the web application.  Another similar booking session with the retry in place resulted in 70 locks, only one of which was not resolved by automatic retries (which was set at a maximum of 3 retries).  We have adjusted to allow 5 retries and are quite happy with this solution.  The vast majority were resolved with only 1 retry but there were a few that needed more.

Thanks,

Joshua

[RobJonkers]

Thanks Joshua for sharing! I will discuss this over with our IMS team and see what we can do to see if a correction makes sense in standard SLcM

Kind regards

Rob

[ezra_schroeder]

Rob,

I filed a note on this issue (0000647644 2014).  But, I have not received a solution to the issue.  I have included the details of the enhancement.

Ezra.

[RobJonkers]

Hi Ezra; will notify our IMS collegians again to look into your message and provide you an answer.

Kind regards

Rob

[RobJonkers]

Ezra; just heard the message is in the status 'customer action'. Can you please check?

[Former Member]

Hi Joshua,

Can you give me more detail information about how you changed program source to avoid object could not be locked error.

[Former Member]

Hi Rob,

Will SAP this issue as standard ?.

If yes, when i can use.

Now i am testing mass module booking and it would be good if i can test in system.

regards,

jin dal

[Former Member]

Hi Colleagues,

One of Korean customer they enhanced in this ways.

Stardard module booking program create SM-ST and ST-E relationship and while trying to create ST-E relationship there is lots of object could not be locked error so thet changed this part just to create ST-E relationship.

in this case there is no object could not be locked error.

regards,