Soren It is also worth noting that ProcessUtils is only used to provide the dataset locking functionality which helps prevents databases being used from multiple JVMs at a time which may be a non-issue on Android since how likely is is that more than one app will try and use the same TDB database?
If this isn't an issue a simpler alternative would just be to disable this feature on Android via the setting: SystemTDB.DiskLocationMultiJvmUsagePrevention = false; Rob On 20/04/2015 03:57, "Andy Seaborne" <[email protected]> wrote: >On 15/04/15 14:49, Sören Brunk wrote: >> Thanks for your suggestions. I got TDB running now. It only required a >> small change in ProcessUtils to get the process id. This adds a >> dependency on the Android sdk though, but it is possible to add a maven >> dependency on the sdk with "provided" scope so I think it's feasible. >> >> According to the log TDB runs in direct mode on my test device as well >> as x68_64 emulator so perhaps detection doesn't work on right on Android >> yet. What would be a good way to test performance? >> >> I think a JIRA is more appropriate for further discussion so I created >> one: https://issues.apache.org/jira/browse/JENA-914 >> >> Cheers, >> Sören > > >Hi Sören, > >Detection is "unsubtle" - it looks for "64" in system property >"java.vm.info" (see SystemTDB.determineIf64Bit()). Adding a "isAndroid" >flag would be good - what's the best way to detect Android that does not >rely on Android code? > >It might be better to run in direct mode on Android anyway as mapped >mode can end up competing for memory resource from other processes while >direct is more controllable. It's a server-style approach where any and >all available free RAM is used for the database. > >In terms of performance, for smallish datasets, or at least >small-RAM-footprint, the performance might be similar. Mapped mode (on >Linux) comes into it's own when queries are repeatedly doing large index >access (e.g. heavy FILTERing). > > Andy > >
