That sounds dodgy - the process seeing the read-only file is going to get its in-memory structures out of sync with the on-disk data.
You should probably explore architectures where the update-process makes some kind of API available so that the monitor process can periodically issue a query. Andrew wrote: > I'd like to inquire about using the FILE_LOCK=NO option for the > following scenario: > > One process creates an embedded database, opened in standard read/ > write mode. This process is responsible for all updates to the data. > We have our own separate locking mechanism to ensure that only one > instance of this process can be running at any given time. > > Another monitor process opens this same database in read-only mode, > and periodically runs simple queries against the data. > > Is disabling the H2 file lock in this situation considered a safe > practice? I've explored the FILE_LOCK=SERIALIZED option already, but > the observed row update latency (about 400 milliseconds) with this > option enabled is well outside of our tolerance range for database > performance. > > thanks, > Andrew > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to h2-database@googlegroups.com. To unsubscribe from this group, send email to h2-database+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
