Multithreading – is there a greendao thread safety best practice?

I've gone with greendao and it's all good so far One thing that doesn't seem to be covered in documents or websites (or anywhere) () is how to deal with thread safety

I know the basics mentioned elsewhere, such as "using a single Dao session" (the general practice of Android SQLite), and I also know a lot about the JAVA memory model The library is even thread - safe, or at least built with this intent But I don't see anything covering this:

Greendao default cache entity This is great for fully single threaded programs - transparency and significant performance gains for most purposes However, if I, for example, LOADALL () and then modify one of the elements, I modify the same object globally throughout the application If I use it on the main thread (for example, display) and update the DB on the background thread (correct and correct), there will be obvious threading problems unless I am very careful

Does greendao do anything under the hood to prevent common application level threading problems? For example, are there any "best practices" to protect cached entities in the UI thread while saving them in the background thread (better hope they don't interleave! Especially when modifying the list), except for general thread safety issues (i.e. greendao expectation and good operation)? Or is there a fatal flaw in the entire cache from the perspective of multithreaded application security?

Solution

I have no experience with greendao, but the document is here:

Say:

Although I can see that the document does not specify multithreading, except for this, it seems clear that it is processed This is talking about multiple threads using the same query object, so it is obvious that multiple threads can access the same database Of course, it is normal for database and Dao to handle concurrent access. In this case, there are many mature technologies that can be used for caching