This is a well known issue with multi-user concurrent access to File Geodatabases. Even with ArcObjects it is a common occurrence. The scenario typically involves read-only access by several client processes (often via a server), conflicting with occasional write-access by the database administrator. The several readers remain active nearly constantly, which effectively blocks the writer.
In ArcGIS 10.1, a new capability has been added to improve this situation. A concept of lock request queuing was added. This behavior is optional and is switched on by changing a setting in the locking system. It adds the notion of mutliple retries for lock requests. Instead of simply failing when a lock conflict exists, the lock is added to a queue. At user controlled time intervals, the lock request is retried a specified number of times. Since read locks are generally short lived, there is a good chance that a write lock request will succeed on retry. Once the write lock request is queued, it takes priority over any subsequent read lock requests.
This new capability has not yet exist in the FileGDB API, but it could be added in a future release.
In the meantime, there is another technique that some users have employed successfully. What they do is have two versions of the File Geodatabase. One is the database that is made publicly available via a server. This database should be placed on a shared folder. The second is the one that is used by the administrator to maintain the data. The second database is not publicly accessible, therefore the admin can do whatever updates are required without having to worry about lock conflicts. Once the second database has been updated, you un-share the public shared folder of the public version and share the updated version. This happens within milliseconds.
If any readers were connected to the original data, they will be "kicked off", but they can re-acquire the connection to the new version.
Hopefully, I have explained this adequately.
