[SERVER-31195] Make ServiceContextMongoDTest support instantiation of different storage engines Created: 20/Sep/17  Updated: 22/Sep/17  Resolved: 22/Sep/17

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Kaloian Manassiev
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Sharding 2017-10-02
Participants:

 Description   

Currently the ServiceContextMongoDTest is the only fixture which instantiates storage engine and many tests depend on that. However it can only create an ephemeralForTest storage engine, which makes it unsuitable for unit-tests, which need to exercise concurrency.

It should be extended with a constructor, which accepts StorageGlobalParams in order to allow it to be configured with a storage engine:

ServiceContextMongoDTest(const StorageGlobalParams& storageParams);



 Comments   
Comment by Githook User [ 22/Sep/17 ]

Author:

{'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}

Message: SERVER-31195 Remove inactive test case from session_test.cpp

Given the semantics of WT to eagerly throw WCE for concurrent writes
instead of waiting until commit time, this test cannot be implemented so I
am removing it.
Branch: master
https://github.com/mongodb/mongo/commit/4fa949bc7c9b50a8043b76b342ab5e6b172c8af9

Comment by Kaloian Manassiev [ 22/Sep/17 ]

Given the semantics of WT to eagerly throw WCE for concurrent writes instead of waiting until commit time, the tests which I wanted to write no longer make sense, so I am scraping this work.

Comment by Kaloian Manassiev [ 21/Sep/17 ]

I should have been more specific in my earlier comment. Ability to throw WCE is not the main reason to be able to specify a storage engine for the test, but the ability to use snapshots, which would allow me to run two concurrent modifications to the same document and have one get rolled back at commit time.

We won't be able to achieve this with ephemeralForTest.

Like we spoke in person, it looks like there is value in allowing the storage engine to be configured. Let me know if you have any problems doing that through passing StorageGlobalParams to the fixture.

Comment by Eric Milkie [ 21/Sep/17 ]

We could also make ephemeralForTest support throwing WCE as needed for unit tests.
I am hesitant to implement this ticket as described, as it would appear to simply be remaking the dbtests flavor of unit test, and we already have a framework for those.

Comment by Kaloian Manassiev [ 21/Sep/17 ]

There is value in being able to write unit-tests that target different storage engines.

Besides, making ephemeralForTest support document level locking will not solve my immediate problem, which is that I want to unit-test what happens due to WriteConflictException.

Comment by Eric Milkie [ 21/Sep/17 ]

Should we do this, or should we make ephemeralForTest support more concurrency?

Generated at Thu Feb 08 04:26:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.