[CONTROLLER-960] Clustering: Minimize overhead of unused data store Tx instances on DOMDataBroker#new*Transaction Created: 27/Oct/14 Updated: 10/Mar/15 Resolved: 10/Mar/15 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | mdsal |
| Affects Version/s: | Helium |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Tom Pantelis | Assignee: | Tom Pantelis |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 2260 |
| Description |
|
When a client creates a transaction via one of the DOMDataBroker#new*Transaction, the broker automatically creates a corresponding DOMStore*Transaction instance in each logical data store (config and operational) although both may not be needed if the client doesn't actually perform an operation (read/put/merge/delete) on a logical data store. This creates unnecessary overhead for the transaction instance and the corresponding (essentially no-op) cohort on submit, particularly for the clustered data store. We can avoid this unnecessary overhead by lazily allocating the DOMStore*Transaction instances for a logical data store when and if the first operation is actually performed on that data store. |
| Comments |
| Comment by Tom Pantelis [ 27/Oct/14 ] |
| Comment by Tom Pantelis [ 28/Oct/14 ] |
|
As pointed out by Robert and Tony in the gerrit: This patch breaks consistency view between two logical datastores - as it was: DOM Broker transaction was snapshot in same time from both datastores, after this patch - DOM Broker transaction is snapshot in time when first type logical data store was accessed - this in reality changes behaviour of implementation in such way, that documented API Contract of DataBroker is not honnored and potentially it also breaks isolation between concurrent transactions. a = newReadWriteTransaction(); a.read(CONFIGURATION,PATH); // Returns null, PATH did not existed at time of allocation a and b. a.put(CONFIGURATION,PATH,foo); b.read(CONFIGURATION,PATH) == foo // Returns true, since backing TX was lazily allocated after a was submitted. I'll drop the patch. Instead I can make changes in the clustered data store to minimize the overhead of unused data store transactions. |
| Comment by Moiz Raja [ 27/Feb/15 ] |
|
You still want to keep this open? |
| Comment by Tom Pantelis [ 27/Feb/15 ] |
|
Yeah - there's some objects created in the constructor that I think we do lazily. (In reply to Moiz Raja from comment #3) |
| Comment by Tom Pantelis [ 01/Mar/15 ] |