Hi Mark, how are you?

fine, and you?

that's a good question

my gut instinct is: try your best to avoid needing to synchronize an operation across processes :-)

:)

I don't recall the Android SDK having a cross-process synchronization mechanism

if you're willing to go into the NDK, you should have some options

I found this but I don't know how good it is http://stackoverflow.com/questions/23893431/how...

that's one of those "it might work, but it seems scary" solutions

yep

Thank you. Never heard of it, I will have to search for some examples.

neither have I; just perusing android.os looking for options

not sure how you use it, considering that it's abstract

but the nice thing about binders is that they are indeed cross-process tokens

but, other than that and doing something in the NDK, I don't have any great ideas

(plus the one that you posted)

how about using file locking

I don't know that Java has strong enough direct support for that, though

not sure if it's even possible. I was thinking one process could open exclusively a file

Android, in terms of being based on Linux, definitely supports file locking

but through the Android SDK, by way of Java, a lot of that gets lost

thing is I want to synchronize SQLite Db access

one of my services could run in a separate process

because of the Android 6 issue with foreground service (if it's in same process with activity it gets killed)

not sure if you remember we talked the other day

I remember you being in the chat; I don't remember the details of the chat itself

or

in theory, SQLite does its own process-level locking

that's a SQLite thing, not an Android thing

I see

so, in principle, with proper transactions, you may be OK

but it's the sort of thing I'd want to beat up fairly seriously in a test suite

and https://www.sqlite.org/wal.html for write-ahead locking

thanks

going back to your file-locking idea: https://developer.android.com/reference/java/ni...

that turned up when hunting around for who all has tried doing multi-process SQLite on Android, and running across: https://github.com/pardom/ActiveAndroid/issues/311

:)

Someone wrote "In Android, FileLock works between processes, but does not work between threads in a process."

that makes sense

how come?

a process has a thread

a process can have N threads

sure.

that comment is saying that FileLock does not do inter-thread locking within a single process

why wouldn't it work across threads in same process?

it's probably backed by POSIX stuff that works at the process level

:(

doesn't make sense to me. it's a file ...

quoting the JavaDocs: " File locks are held on behalf of the entire Java virtual machine. They are not suitable for controlling access to a file by multiple threads within the same virtual machine. "

apparently, that scope was a decision made by Sun, back when they added FileLock to Java

I see

back to the SQLite locking, see also section #2 in http://sqlite.org/howtocorrupt.html

another possibility would be for you to use a ContentProvider to expose access to the database (from your main process) to the service (running in the separate process)

makes my head spin. I think that's why I got the idea from somewhere it's better to do your own locking

that way, all database I/O runs through one process

I need to refresh my memory but AFAIK ContentProvider requires an Activity

nope

ok I will do some research

your app needs an activity, in order for any of your code to run

but a ContentProvider itself is not tied to an activity

my guess is that this will be an area that gets more attention in the coming years, due to the sorts of problems that you're running into

that, of course, does not exactly help you now

thank you Mark

sorry that I didn't have a sure-fire silver bullet for you

not a problem

discussion has been very helpful to me

I will stick around

that's the end of today's chat

the transcript will appear on https://commonsware.com/office-hours/ shortly

the next chat is Tuesday, also at 7:30pm US Eastern

have a pleasant day!