From: jj_in_atlanta on
I'm getting errors in my trace logs (and in the application event log) about
a concurrency exception. It happens every 5 minutes and has been doing so
for quite awhile it seems.

There is a critical exception:
The Execute method of job definition
Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition(ID [guid])
threw an exception

but the trace log entry with the most useful info is this one:
OWSTIMER.EXE (0x00EC) 0x0BE0 Windows SharePoint Services Topology
75bd High
UpdatedConcurrencyException: The object SPSearchDataAccessServiceInstance
Parent=SPServer Name=EAVDEVWSS01 was updated by another user.
Determine if these changes will conflict, resolve any differences, and
reapply the second change.
This error may also indicate a programming error caused by obtaining two
copies of the same object in a single thread.
Previous update information: User: DOMAIN\account1 Process:OWSTIMER
Machine:EAVDEVWSS01 Time:May 15, 2007 04:05:00.0000
Current update information: User: DOMAIN\account1 Process:OWSTIMER
Machine:EAVDEVWSS01 Time:August 02, 2007 01:50:00.2266

Any idea how I can clear the concurrency issue?
From: Wei Lu [MSFT] on
Hello JJ,

I found that this issue is caused by a disaster recovery. The file-system
cache on the front end is newer than the contents of the configuration
database. After a disaster recovery, it may be necessary to manually clear
the file system cache on the local machine.

Resolution
=============================
Clear the file system cache on all servers in the farm running the timer
service manually. To do this, stop the timer service, delete (or move) the
contents of the folder at
%ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\<someGuid>

Then, simply restart the timer service. The cache will be rebuilt and the
issue should disappear. This should be done on every machine in the farm
running the timer service

Hope this helps!

Sincerely,

Wei Lu
Microsoft Online Community Support

==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
From: jj_in_atlanta on
That fixed it - thank you very much for your assistance.

"Wei Lu [MSFT]" wrote:

> Hello JJ,
>
> I found that this issue is caused by a disaster recovery. The file-system
> cache on the front end is newer than the contents of the configuration
> database. After a disaster recovery, it may be necessary to manually clear
> the file system cache on the local machine.
>
> Resolution
> =============================
> Clear the file system cache on all servers in the farm running the timer
> service manually. To do this, stop the timer service, delete (or move) the
> contents of the folder at
> %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\<someGuid>
>
> Then, simply restart the timer service. The cache will be rebuilt and the
> issue should disappear. This should be done on every machine in the farm
> running the timer service
>
> Hope this helps!
>
> Sincerely,
>
> Wei Lu
> Microsoft Online Community Support
>
> ==================================================
>
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
>
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no rights