A Realm holds a read lock on the version of the data accessed by it, so that changes made to the Realm on different threads do not modify or delete the data seen by this Realm. Calling this method releases the read lock, allowing the space used on disk to be reused by later write transactions rather than growing the file
Is there a matching function in Xamarin.Realm like in Objc/Swift's RLMRealm invalidate.
If not, is this a backlog item or is it not required(?) with the C# wrapper.
I think calling Realm.Refresh() would be a workaround - it will cause the Realm instance to relinquish the read lock it has at the moment and move it to the latest version which would free up the old version for compaction.
Ordinarily moving the read lock to the latest version would happen automatically if the thread you run on has a running CFRunLoop or ALooper, but on a dedicated worker thread you'd be responsible for calling Refresh() on your own to advance the read lock.
Please open an issue on https://github.com/realm/realm-dotnet for Invalidate() if Refresh() doesn't work for you.
I think you would use Realm.Close(). See:
https://realm.io/docs/xamarin/latest/api/class_realms_1_1_realm.html#a7f7a3199c392465d0767c6506c1af5b4
Closes the Realm if not already closed. Safe to call repeatedly. Note that this will close the file. Other references to the same database on the same thread will be invalidated.
Related
I am using Interop.Domino to work with .NSF file. To generate the html mime entity I used the nnote but in some case it failed to generate it so in that case I took the RTFTEXT / PLIAN TEXT as output.
so I used CreateMIMEEntity for it.
NotesMIMEEntity MIMEBody = NoteDocument.CreateMIMEEntity("Body");
It works but it holds the control on the Database (.nsf file), file is getting mark as being used in another process.
By troubleshooting it it clear that above statement holds the control.
I have released all the Note objects assigned with it.Still problem remains same.
Is there are proper way to use it or release it?
The Notes core DLLs that are underneath the COM classes keep databases open in cache. The only way that I know of to close them is to terminate the process that loaded the DLLs. One option is to design code using the COM API so that it dispatches short-term worker processes to open the database, do the work, and terminate. Yeah, it's ugly and slow, but if you need a long-running service and you're using the COM API instead of the Notes C API, it's the best way.
In any case, the cached open databases should not cause a sharing violation if you are opening the database through the Domino server. If you are using "" instead of the server name when opening the database however, it's going to be a problem -- and you shouldn't even do that in short-running worker processes.
After deleting some items from my db i get this -> Realms.RealmInvalidObjectException: This object is detached. Was it deleted from the realm?
In Realm Xamarin, you have to use RealmResult Notifications to be notified of when there is a change to your database.
Considering Realm is zero-copy and the objects you obtain from it are just proxies to the underlying database, if you delete an object on any thread, then that object will be deleted on every thread in Realm's latest snapshot for the thread.
So it's best if you always make sure you're notified of changes in your result set and update the UI accordingly, and handle the case when your objects could have been deleted due to some operation (by making sure they're still valid).
I have the following situation:
One process is reading from a SQLite database.
Another processes is updating the database. Updates do not happen very often and all transactions are short. (less than 0.1ms on average)
The process that is reading should have low latencies for the queries. (around 0.1ms)
If the locking of SQLite would work like a mutex or readers-writer lock, everything would be ok.
From reading http://www.sqlite.org/lockingv3.html this should be possible. SQLite is using
LockFileEx(), sometimes without the LOCKFILE_FAIL_IMMEDIATELY, which would block the calling
process as desired.
However I could not figure out how to use/configure SQLite to achieve this behavior. Using a busy-handler
would involve polling, what is not acceptable because the minimal sleep time is usually 15ms on Windows.
I would like that the query is executed as soon as the update transaction ends.
Is this possible without changing the source code of SQLite. If not, is there such a patch available somewhere?
SQLite does not use a synchronization mechanism that would wait just until a lock is released.
SQLite never uses a blocking locking call; when it finds that the database is locked, is waits for some time and tries again.
(You could install your own busy handler to wait for a shorter time.)
The easiest way to prevent readers and a writer from blocking each other is to use WAL mode.
If you cannot use WAL mode, you can synchronize your transactions by implementing your own synchronization mechanism: use a common named mutex in all processes, and lock it around all your transactions.
(This would reduce concurrency if you had multiple readers.)
Ok, so I get the gist of MediaFoundation:
When I start my App I create an IMFMediaSession.
When I want to play a file I create an IMFMediaSource, create the necessary IMFTopology, and I set it to the IMFMediaSession. Depending on the flag used (dwSetTopologyFlags) the new media source will either play immediately or just get added to a queue to be played by the MediaSession when the existing topologies/mediaSources are done playing.
Now my issue is cleaning up after old media sources.
Is there an event that is sent by the MediaSession right before the topology used is about to be removed? That way I could access the media source from there and call ShutDown on it (thus avoiding memory leaks) without having to keep references to previous mediaSessions myself in my code.
//=============================================================================== Update:
According to MSDN:http://msdn.microsoft.com/en-us/library/windows/desktop/aa372153%28v=vs.85%29.aspx
I need to call ShutDown on any IMFMediaSource I create, before releasing it.
With this in-mind, mixing MFSESSION_SETTOPOLOGY_FLAGS (immediate/clear_current with no flags) can cause a memory-leak, as the Session removes topologies from its queue without my application having the chance to call shutdown on their sources.
Also, if I call Shutdown on the current mediaSource before the next mediaSource's topology has been set (i.e. before I get the MESessionTopologyStatus event) then I can't playback the next mediaSource. Why? I don't know, msdn does not explain what resources are released when I call shudown on a mediaSource, so I guess something I still need in order to play the next mediaSource is being released...
My experience is that if you do not call Shutdown on Source, you will have memory leak. Check my project MFNode. There is a custom MediaSession (MFNodePlayer project).
If you uncomment the call to Shutdown on the source, you will see memory leak.
A lot of source expect you call Shutdown because you need to wait stop message from the source (they are usually asynchronous).
If you try to use the the source before it stops, you will face some strange error/behaviour and memory leak.
You have to wait the source to stop, in order to have a stable application. And calling Shutdown on source is here for that.
While writing a driver, I came across a issue mentioned below.
Given a multithreaded application accessing the same device file through same FD. Consider that between the calls to OPEN and RELEASE, there are some resources (say mutex) held mutually by the thread-group. These resources are used during the READ/WRITE calls, and then eventually given up or destroyed during RELEASE.
If there is one thread accessing the resource during READ/WRITE and another thread simultaneously invokes the RELEASE by calling close, how is it assured by the VFS that the RELEASE is not called until there is at least one thread in the READ, WRITE, or like. What mechanism is handling this protection?
The kernel layer above the device drivers keeps track of how many references to an open file exist and does not call the release function until all of those references have been closed. This is somewhat documented in LDD3: http://tjworld.net/books/ldd3/#TheReleaseMethod