When a user is entering their time and the click on save, they sometimes get the following error message:
An error has occurred. The time sheet or its work items has been updated by another user. Please refresh to continue with your changes.
If the user clicks refresh, they need to reenter everything again (as it was lost) and when they click on save/submit they get the same error message. The workaround is to get out of the time sheet entirely and then go back in. What I want to know is how to prevent this error in the first place.
Probably related ... the PM's also get a very similar error (someone has updated the budget) when making changes to their budget then clicking save. The workaround for this is to make one change then save - but that can be time consuming and annoying.
I am having my sys admin guy contact HP Support directly - but I thought I'd trow this out there to some of the other experts.
7.x uses background services to do the roll-ups of things like project costs and if you have a somewhat slow server (like we have) then the services can step on a user's transaction, or vice versa.
We have experienced the same issues, and have mostly solved them by running two PPM JVMs - one for users and one for services only - on the same physical server. This seems to help the services run faster.
I'm attaching a doc on this in case you want to explore that route.
Just wanted to let you know that we are having the same type of problems, and have also an open case with HP. In addition we are also on 7.1 SP8.
In our case we ARE running seperated user and services node and we still have these errors frequently.
In our case it is probably related to the Cost update service that is running, as we usually see this more frequently when it is initated. It seem to be a problem in regards on how this service claims record for updates.
Thanks Johannes. I am not sure if I should feel better or not :o)
Now that you say that - that reminded me of a change we made - where we shortened the Cost, Exception, and Health autocalculation from the default 60 minutes to 5 minutes. 60 was way too long when our PM's were making changes to the work plan and wanted to see what it did to their budget.
Eric, sorry for my late reply, I didn't realise you responded. We are running an external Apache on windows webserver, solaris app server and solaris oracle server. We recently upgraded the app server as well as load balancing the user nodes but that rather added to the problem for some strange reason.
We still have this issue and we are not able to implement any of the suggestions at this point - as it would require some funds.
It has been confirmed the reason IS because we changed the frequ of the cost & health calculations from 60 minutes to 5 minutes. So far it is more important that the cost calcs are updated every 5 minutes versus some users getting the error messages - for now.
It would be nice if HP redesigned this in future updates so that they do not clash with each other. Maybe a manual calc button for the PM?
Anyway ... unless there is a better way then what has been presented thus far - then we will live with the issue for now.
Sorry I missed following up earlier. Since March we have changed our hardware configuration and are now able to run the cost interval at 20 minutes without any issues.
Before, we were running the app server on a 16-CPU Solaris box. Now, we moved our app server to a VM environment aboard a Linux box and have since found the response times to be vastly (2-3 times) better.
PPM is running on a Suse Linux 11 Enterprise installation within VMware ESX 3.5.4. The server is allocated 2 GB of virtual RAM and 2 virtual processors. The actual CPUs are dual core 2.67Ghz processors(4).
We handle only 20-30 actual simultaneous users, and 20 or so concurrent projects so we were surprised to have such poor performance from the Solaris box (16x1GHz processors, 8GB ram). Time-sheet contention (as in original post) and graphical portlet performance were the biggest pain points.
We are using the PPM internal web server, split with a "user" instance and a "services" instance both running on the same Linux VM. DB is still on our RAC cluster, no change there.
Our server folks recommended the Linux setup based on the type of CPU architecture and how well it works with Java. We now have more "floating point" CPU power (so they tell me), and our services and graphical portlets now run in 1/2 to 1/3 the time, no joke.