PX Failure

We  have a PX on Update Title block of MCO (Synchronous) . PX updates few attributes of Affected Items. 

Sometimes PX Fails and below is the message that can be seen in Monitor.

1. Someone is working on this object. Please try later
2. This object has been modified.Please refresh and try again

When the PX is re run again manually, it is successful.

(There are Update Title Block PX’s for Items)

This error occurs rarely. Can you please help me with the reasons for the 2 errors

Agile User Asked on August 28, 2017 in Agile PLM (v9),   Product Collaboration.
Add Comment
3 Answer(s)
Best answer

Hi Raju,

This is pretty much normal scenario in Agile. It happens due to object lock which is created when code takes longer time to execute or multiple clicks performed to execute the code. 

One way i handle this thing is to introduce a counter on number of re-tries you wanna do. 

Something like this i tried in my code and it helped :

catch (APIException e)
message = e.getMessage();
if (message.contains(“This object has been modified”)
|| message.contains(“Someone is working on this object”)) {
if (trynumber < 3) {
//Call your code once again. 

} else {
//verify the number of tries e.g. u can print try number.
// Call your code once again

} else {
//Send final failure message


Agile Angel Answered on August 28, 2017.

catch (APIException e)

Used to throw null pointer sometimes and when px is re run it is successful.

I have changed it to

catch (APIException e)

And i have observed 2 messages

1. object has been modified.
2.someone is working on this object.

Can this issue cause Nullpointer Exception?
please help me

on August 28, 2017.

No, this doesn’t result in NPE.

However, I see you have two back to back Catch block and both have APIException e signature. Can you change it in second block to something like ex. Also, when i used it, i had only one Catch block. 

on August 28, 2017.

I have only one catch block currently

Catch(APIException e )
What could be the possible cases of Null pointer exception as the PX is successful when it is re run on same object.

Earlier in the catch block
It was obj.logMonitor(e.printStackTrace()) instead of obj.logMonior(e.getMessage())

on August 28, 2017.

Are you using a custom logger to log this messages or you are using obj.logMonitor only.

on August 28, 2017.

Obj.logMonitor only

on August 28, 2017.

Okay. I did it with custom loggers.

on August 30, 2017.
Add Comment

Slightly off topic, but use of logging is recommended to actually capture the error as well as where in the source code line the error occurred ( %L in log4j ).

Since it’s hard to generate PX specific log file, a quick hack I used to generate a log for one specific PX was to setup log4j parameters dynamically within the PX code by 
1) had a env or hardcoded location where the PX will first read a properties file that contain directives tied to log4j parmaters
2) programatically call the same log4j method

If log4j.properties are like this:

log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L – %m%n

You should have something in code to mimic it…. Note: make sure that you DO NOT create multiple loggers writing same log to the same file… create logger only once.

RollingFileAppender rfa = new RollingFileAppender();
rfa.setLayout(new PatternLayout(“%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L – %m%n”));

Agile Talent Answered on October 18, 2017.
Add Comment

I am facing the same issue and planning to implement counter method as suggested by Arif to handle it. But while investigating this error found metalink which suggest this issue has been taken care in version 9.3.6 URL:Someone is working on this object. Please try again later .

I am getting the same error and I know why its causing. In my case I have Event Px which works on Update Of Cover Page for Change Order and I have another PX which create ECO update descriptipn, updatede reason, add items, redlines etc… So whenver there is update for ECO cover page other px runs simultaneously and resulting in the error.

I was just curious if this issue is really fixed in 9.3.6. Please let me know whoever is working on 9.3.6


CMSessionBean.logUserDefinedActionWOVersionChange(…) was locking the object and the event was not recorded correctly.
This is explained on the following bug:


This issue is resolved in Agile PLM 9.3.6. Upgrade to Agile PLM 9.3.6 or above.

Agile Angel Answered on April 12, 2019.
Add Comment

Your Answer

By posting your answer, you agree to the privacy policy and terms of service.