My Email doesn't appear have come through.. sending again.
Sounds like trouble there!. A would still be updating metadata, and if B
is reading from metadata then it might be in a corrupted state. That
would be my guess. Have no idea really. But I wouldn't do it if you were
counting it on it work consistently. Might work 99.9% of the time then
do something strange. I might be completely off though.
On 1/03/2015 2:00 AM, Johann Petrak wrote:
Thanks -- this is what I had been thinking, but I thought it would be
better to bring it up since
this option is not explicitly mentioned in the documentation.
Another interesting situation is where two processes access the same
database, again in embedded
mode, and one of the processes updates just table A while the second
process just reads from table B.
Would it be safe for the second process to open the database in
read-only mode and without locking, while
the first process opens it r/w and creates a lock file and would they
interfere with each other?
On 28 February 2015 at 17:43, Ryan How <r...@bitworks.com.au
<mailto:r...@bitworks.com.au>> wrote:
I'll let someone more qualified give you a better answer.
But, yes I can't see any reason why it wouldn't work (The same as
if it was on a read only filesystem?)
I find embedded mode has better performance, but it is more
profound in lots of smaller queries. If it is larger less frequent
queries there isn't as much difference.
You might have to test your specific case if you are trying to
squeeze every bit of performance possible.
Not sure if the cache might be better with the server though.
Otherwise each process will have it's own cache.
On 28/02/2015 8:49 PM, Johann Petrak wrote:
Is it possible, safe and reasonable to add
;FILE_LOCK=NO;ACCESS_MODE_DATA=r
to the URL from two processes which use the same database in embedded mode?
If yes, can I expect better performance from doing it that way than from
using a local server?
thanks
johann
--
You received this message because you are subscribed to the
Google Groups "H2 Database" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to h2-database+unsubscr...@googlegroups.com
<mailto:h2-database+unsubscr...@googlegroups.com>.
To post to this group, send email to h2-database@googlegroups.com
<mailto:h2-database@googlegroups.com>.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in
the Google Groups "H2 Database" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/h2-database/JtWn2CjvIp0/unsubscribe.
To unsubscribe from this group and all its topics, send an email
to h2-database+unsubscr...@googlegroups.com
<mailto:h2-database+unsubscr...@googlegroups.com>.
To post to this group, send email to h2-database@googlegroups.com
<mailto:h2-database@googlegroups.com>.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "H2 Database" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to h2-database+unsubscr...@googlegroups.com
<mailto:h2-database+unsubscr...@googlegroups.com>.
To post to this group, send email to h2-database@googlegroups.com
<mailto:h2-database@googlegroups.com>.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
