[SERVER-31649] CachedCollectionProperties::getCollectionProperties accesses the collection with only DB IS lock Created: 19/Oct/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 3.4.9, 3.6.0-rc0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Replication
|
| Operating System: | ALL |
| Participants: |
| Description |
|
This code in CachedCollectionProperties::getCollectionPropertiesImpl accesses the collection while only holding a database IS lock. While in practice this may work, because dropping a collection takes database X lock, technically the collection object is not stable without some form of collection lock, which in this case should be IS. |
| Comments |
| Comment by Siyuan Zhou [ 09/Apr/20 ] | ||
|
This still seems a problem even if we don't need DB locks any more. geert.bosch, I'd like to double check that we still need the collection lock before access the catalog. | ||
| Comment by Chibuikem Amaechi [ 23/Dec/17 ] | ||
|
Hi everyone, I am a new server contributor and would like to be assigned this ticket. My proposed change would be to add the statement
right underneath the statement
in CachedCollectionProperties::getCollectionPropertiesImpl. This new statement would then allow the collection to be accessed with a Collection IS lock; thus, making it stable. Please share your thoughts. Best Regards, |