Re: [h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

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 Gra

Re: [h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

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&q

Re: [h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

> 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

Re: [h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

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

Re: [h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

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

Re: [h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

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

Re: [h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

... ... Answer this: Is LOCK_MODE=0 to disable ALL locking or just some locking? The documentation suggests ALL locking is disabled. And if the answer is ALL, then clearly from the log file this is not happening. For testing I added code: this.lockMode = ci.getProperty("LOCK

Re: [h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

On 4 January 2018 at 02:22, Patrick H <tengai...@gmail.com> 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.

Re: [h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

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

[h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

want to unlock something when it wasn't locked? Patrick On Wednesday, January 3, 2018 at 4:22:32 PM UTC-8, 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 > n

[h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

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 Constants.DEFAULT_LOCK_MODE (3). Patrick On Wednesday, January 3, 2018 at 3:17

[h2] Re: With LOCK_MODE=0, log file still has hundreds of locks

; } database.getLockMode() is returning '3' as opposed to '0'. I'm trying to determine if LOCK_MODE=0 is passed to the database object. Patrick On Wednesday, January 3, 2018 at 11:33:54 AM UTC-8, Patrick H wrote: > > Hello, > > I am using: > > java -Xmx4096m -Xverify:none -cp %CLASSPA

[h2] With LOCK_MODE=0, log file still has hundreds of locks

Hello, I am using: java -Xmx4096m -Xverify:none -cp %CLASSPATH%\h2-1.4.196.jar org.h2.tools.RunScript -url "jdbc:h2:nioMapped:~/%DB_NAME%;LOCK_MODE=0;TRACE_LEVEL_FILE=3;UNDO_LOG=0" -user "admin" -password "admin" -script "D:/dev/sql/sqlscript.sql" a

Re: [h2] LOCK_MODE=0 and read-only database

if you're not doing any updates then LOCK_MODE=0 won't make much difference, ​ -- 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-databas

[h2] LOCK_MODE=0 and read-only database

Is there any potential harm setting LOCK_MODE=0 on a read-only database? Would this increase the speed of SELECTs on database? -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving e

Re: [h2] MULTI_THREADED=1 fails after LOCK_MODE=0, no exception

) setting LOCK_MODE=0, connecting to the same or another db with the global setting MULTI_THREADED=1 fails. One needs to reset the lock mode with LOCK_MODE=3. This has been noted by https://groups.google.com/forum/#!msg/h2-database/ chvHwUZ20xQ/sYgNWLVSUXQJ and it's the only place after 2 hrs

[h2] MULTI_THREADED=1 fails after LOCK_MODE=0, no exception

The situation: after a db import with the suggested (persistent) setting LOCK_MODE=0, connecting to the same or another db with the global setting MULTI_THREADED=1 fails. One needs to reset the lock mode with LOCK_MODE=3. This has been noted by https://groups.google.com/forum/#!msg/h2-database

[h2] Re: LOCK_MODE

Hi, I'm wondering whether there are any plans in H2 to address Dario's concerns below. The plan is to use PostgreSQL-style read committed in the future by default, with the new MVStore storage engine. That means MVCC. LOCK_MODE=0 will most likely no longer be supported. Regards, Thomas

Re: LOCK_MODE

/Isolation_%28database_systems%29). Thanks Remo On Friday, August 20, 2010 3:14:30 PM UTC+2, dariof wrote: Hi Thomas, I'm somewhat confused by how you both refer to TRANSACTION_ISOLATION_LEVEL and LOCK_MODE as if there were the same thing. Even the documentation makes a parallel between

Re: Connecting to h2db with 'MULTI_THREADED=TRUE' option which was already opened with 'LOCK_MODE=0' option.

Hello, Thank you for your answers. I will set LOCK_MODE to 3. On Friday, February 15, 2013 11:54:29 AM UTC+3, Thomas Mueller wrote: Hi, The setting LOCK_MODE is persistent, as documented: http://h2database.com/html/grammar.html#set_lock_mode - so the setting is stored in the database

Connecting to h2db with 'MULTI_THREADED=TRUE' option which was already opened with 'LOCK_MODE=0' option.

Hi, I create H2DB as a file and import the huge amount of data with Fast Database Import options: http://www.h2database.com/html/performance.html#fast_import. LOG=0;CACHE_SIZE=65536;LOCK_MODE=0;. After import of data I open connections with 'MULTI_THREADED=TRUE' option only for reading

Re: emergency: How to kill the uncommit read lock on other session when lock_mode 1/2 ?

Hi, Sorry I can't reproduce the problem. In my test, the lock gets released as soon as the connection is closed. Could you post a reproducible test case? Regards, Thomas On Friday, May 18, 2012, 齐哲之 wrote: Hi, I had a problem. Lock_mode 1 or Lock_mode 2. Two or more session on one

emergency: How to kill the uncommit read lock on other session when lock_mode 1/2 ?

Hi, I had a problem. Lock_mode 1 or Lock_mode 2. Two or more session on one database, test1 for example. session_id 1: select * from t1 session_id 2: select * from t1 select * from information_schema.locks then there are two read locks. then I close session_id 2 without commit. select * from

Re: Same URL but 'Cannot change the setting LOCK_MODE=0 MULTI_THREADED'

or seconds connection). Regards, Thomas On Wed, May 4, 2011 at 7:58 AM, kensystem kensys...@gmail.com wrote: Hi, I have one open connection in TCP mode (h2-1.3.152.jar), then attempting to open another, the server throws: JdbcSQLException: Cannot change the setting LOCK_MODE=0 MULTI_THREADED when

Same URL but 'Cannot change the setting LOCK_MODE=0 MULTI_THREADED'

Hi, I have one open connection in TCP mode (h2-1.3.152.jar), then attempting to open another, the server throws: JdbcSQLException: Cannot change the setting LOCK_MODE=0 MULTI_THREADED when the database is already open; [90133-152] Is this throw correct, considering that the URL is the same

Re: LOCK_MODE

Hi, you can clearly see that this setting is meant by the jdbc designers to be connection specific. There is no Database interface in the JDBC API, but that's not the point. H2 currently doesn't support setting this property differently for each connection. Regards, Thomas -- You received

Re: LOCK_MODE

Hi, clearly against the JDBC api The JDBC API doesn't dictate what features a database needs to support exactly. Regards, Thomas -- You received this message because you are subscribed to the Google Groups H2 Database group. To post to this group, send email to h2-datab...@googlegroups.com.

Re: LOCK_MODE

Hi Thomas, I'm somewhat confused by how you both refer to TRANSACTION_ISOLATION_LEVEL and LOCK_MODE as if there were the same thing. Even the documentation makes a parallel between the two when might be different things. Lock mode is a resort to achieve a transaction isolation level

Re: LOCK_MODE

Hi, My question is this: If I connect with url jdbc:h2:test;LOCK_MODE=0 does it also affect other connections (and transactions) or only the one connection that set the mode in it's url? This is documented: This setting affects all connections. Regards, Thomas -- You received

Re: LOCK_MODE

But in JDBC api Connection interface has method void setTransactionIsolation(int level) So it is clearly against the JDBC api if this setting affects all the other connections also. - Rami Ojares Thomas Mueller wrote: Hi, My question is this: If I connect with url jdbc:h2:test;LOCK_MODE=0

LOCK_MODE

Hi, In documentation for SET LOCK_MODE there is the following sentence: This setting is persistent. My question is this: If I connect with url jdbc:h2:test;LOCK_MODE=0 does it also affect other connections (and transactions) or only the one connection that set the mode in it's url? In other

Re: Questions around LOCK_MODE

May be I should clarify: I always saw WRITE locks, but no READ locks. Then I checked the SETTINGS, but LOCK_MODE was not listed. I then set LOCK_MODE to 1 and since then it works correctly for both READ and WRITE locks. So it seems to be, that the LOCK_MODE parameter was somehow not set when