Timeline for Concurrent non-blocking update of cached list of on-line users
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Aug 16, 2020 at 19:42 | history | suggested | Bogdan Mart | CC BY-SA 4.0 |
Fixed broken link using Web Archive
|
| Aug 16, 2020 at 19:33 | review | Suggested edits | |||
| S Aug 16, 2020 at 19:42 | |||||
| Aug 16, 2020 at 19:31 | comment | added | Bogdan Mart | Microsoft broken internet again and your link is not available :( | |
| Jun 8, 2016 at 12:47 | vote | accept | Bogdan Mart | ||
| Jun 2, 2016 at 10:30 | comment | added | Dmitry Nogin |
@Heslacher We usually suppose to take ownership - it is a default recommended behavior in .NET. If otherwise is required, then our ctor should have a special parameter keepOpen with default value equals false. This is how we define classes. Interfaces could be done differently, w/o inheriting from IDisposable, so concrete implementation will implement it directly only when necessary. The last approach work well for IoC containers, but taking ownership requires an extra cast attempt, which complicates things. It all depends :)
|
|
| Jun 2, 2016 at 10:13 | comment | added | Heslacher |
About Dispose: The mentioned link is meant IMO that if you have a type which is likely to be extended and the extended type holds unmanaged resources then you should implement dispose. For the class in question, wouldn't you be surprised if the TextWriter object is disposed after you pass it to the constructor and after you dispose that class ? Clearly the responsibility to dispose objects should be at the creator of the object.
|
|
| May 31, 2016 at 22:37 | history | edited | Dmitry Nogin | CC BY-SA 3.0 |
added 320 characters in body
|
| May 31, 2016 at 22:22 | comment | added | Dmitry Nogin | @BogdanMart Yep, it definitely should work. Thank you for sharing it! | |
| May 31, 2016 at 21:24 | comment | added | Bogdan Mart |
There is no way to ensure that its state is not changed while you removing it. It checks by Equility, I guess even if I put Session object instead of timestamp that will still work. And Session is immutable.
|
|
| May 31, 2016 at 21:22 | comment | added | Bogdan Mart | @Dmitry-Nogin I've checked Dictionary code. It locks bucket, then finds internal Node by key, and than chcks if value haven't changed, if value chaged it returns false, if value haven't changed it removes it. github.com/dotnet/corefx/blob/master/src/… github.com/dotnet/corefx/blob/master/src/… | |
| May 31, 2016 at 21:13 | comment | added | Dmitry Nogin | @BogdanMart 3. ValueObject is really fast actually. | |
| May 31, 2016 at 21:10 | comment | added | Dmitry Nogin | @BogdanMart 2. You can remove KVP, but there is no way to ensure that its state is not changed while you removing it. You could probably try to inspect the KVP after removing and push it back if changed, but the same key entry might already be created and reported as a new one at the moment. The only safe way – is to mark for removing by assigning null, which prevents updates and additions while you confirming your operation. | |
| May 31, 2016 at 21:10 | comment | added | Dmitry Nogin |
@BogdanMart 1. I would not suggest to use AgentId in Entity Types, but it is compatible with Linq to Entities, so you can do context.Agents.Where(a => session.AgentId) where session.AgentId is our Value Object field. Conversion operators make integration easy.
|
|
| May 31, 2016 at 20:49 | comment | added | Bogdan Mart | How slow is ValueObject is, compared to regular objects, with manual equals? it's seems to create some overhead, but looks really nice. | |
| May 31, 2016 at 20:48 | comment | added | Bogdan Mart | I'm not sure why MS didn't made that signature public, but if cast to ICollection, we can remove by KV pair. So it removes atmicaly at one call, why do we need to make 3 calls? Idea with session object is great too, we can store more useful info. I've learned many new, but please clarify with Remove. | |
| May 31, 2016 at 20:46 | comment | added | Bogdan Mart |
Thanks for your time, Moitry. It's seems pretty cool. I really like concept of AgentId and ValueObject. I'll try to propagate AgentId like structs to EF using [ComplexType]. Can you explain why do we need to put null into dictionary before deletion? I'm using special overload of remove, that takes KeyValuePair, that checks both Key and value, if value!=stored it returns false. it utilises internal method TryRemoveInternal(keyValuePair.Key, out obj, true, keyValuePair.Value);.
|
|
| May 31, 2016 at 20:31 | comment | added | Dmitry Nogin |
Thanks. As for Dispose - Microsoft suggests it for all the streaming classes: CONSIDER implementing the Basic Dispose Pattern on classes that themselves don’t hold unmanaged resources or disposable objects but are likely to have subtypes that do.
|
|
| May 31, 2016 at 8:33 | comment | added | Heslacher |
Nice answer. I would remove the parameterless constructor in SessionLogWriter. In that way you can omit the Dispose and IDisposable because an object which is passed to the constructor which takes a TextWriter should be disposed by the object which created it. Otherwise +1
|
|
| May 31, 2016 at 7:16 | history | edited | Dmitry Nogin | CC BY-SA 3.0 |
added 31 characters in body
|
| May 31, 2016 at 4:50 | history | answered | Dmitry Nogin | CC BY-SA 3.0 |