I don't see how calling RUNSCRIPT is abnormal, but OK.
I'll see about adding fix:
this.lockMode = ci.getProperty("LOCK_MODE", Constants.DEFAULT_LOCK_MODE);
to constructor:
Database(ConnectionInfo ci, String cipher)
On Friday, January 5, 2018 at 11:09:39 AM UTC-8, Noel Grandin wrote:
>
>
LOCK_MODE=0 is not something we have a lot of test coverage for, so I only
know that is works for normal cases.
You're more than welcome to submit patches to fix your specific use-case.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To
> Why this is happening for you I don't know.
Are you suggesting it doesn't happen to you?
Has there been any testing that focuses on RUNSCRIPT being used in a SQL
script file?
>From my testing calling RUNSCRIPT seems to seriously alter the designed
behavior of H2.
Locking is unreliable
Yup, it should disable all locking. Why this is happening for you I don't
know.
--
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
No, locking is happening throughout. I see locking happen with every
sub-RUNSCRIPT.
Why is locking even happening? Again, is LOCK_MODE to disable ALL locking
or not?
On Thursday, January 4, 2018 at 11:13:23 AM UTC-8, Noel Grandin wrote:
>
> what you are seeing is just the locking we do
what you are seeing is just the locking we do during startup.
--
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
Yes, I have done that (breakpoint on setLockMode) and it is not called
before these log outputs:
2018-01-03 11:04:28 lock: 1 exclusive write lock requesting for SYS
2018-01-03 11:04:28 lock: 1 exclusive write lock added for SYS
2018-01-03 11:04:28 lock: 1 exclusive write lock unlock SYS
...
...
On 4 January 2018 at 02:22, Patrick H wrote:
> Constructor, public Database(ConnectionInfo ci, String cipher) where all
> the URL options are parsed never parses for the 'LOCK_MODE' option. Thus
> never changes the default value for Database.lockMode which is
>
On 4 January 2018 at 02:48, Patrick H wrote:
>
> Why would you want to unlock something when it wasn't locked?
>
>
>
Because updateMeta will lock it, and we don't want to unlock it if it was
previously locked.
--
You received this message because you are subscribed to the