Hi Noel, You was right, multi_threaded=true works fine. I can't see a thread blocking any more, but then h2 documentation has to be edited.
Thank you. On Saturday, April 18, 2015 at 7:15:11 PM UTC+3, sim wrote: > > Hi Noel, > Thank you for your answer. Do you think it helps? Then please explain for > this: > > > Multithreading Support > > This database is multithreading-safe. That means, if an application is > multi-threaded, it does not need to worry about synchronizing access to the > database. Internally, most requests to the same database are synchronized. > That means an application can use multiple threads that access the same > database at the same time, however if one thread executes a long running > query, the other threads need to wait. > In my case I have a thread with long running (~10s) query and I suspect > database block another > thread with another query. I hoped that MVCC had to solve this case or I > something don't understand. > > > > > On Saturday, April 18, 2015 at 5:46:35 PM UTC+3, Noel Grandin wrote: >> >> If you are not using the mvstore directly, then to get concurrency you >> will need to add MULTI_THREAD=TRUE to your URL. >> Just be warned that we are still thrashing the bugs out of that mode. >> On Sat, 18 Apr 2015 at 15:27, sim <[email protected]> wrote: >> >>> Hi Noel, >>> >>> Just extra information - >>> >>> Tables >>> ======= >>> >>> CREATE TABLE CLIENTS ( >>> CL_ID BIGINT NOT NULL, >>> CL_NAME VARCHAR(1024) DEFAULT '' NOT NULL, >>> CONSTRAINT CLIENTS_pk PRIMARY KEY (CL_ID) >>> ); >>> >>> CREATE INDEX CLIENTS_idx >>> ON CLIENTS >>> ( CL_NAME ASC ); >>> >>> CREATE TABLE REQUESTS ( >>> REQ_ID IDENTITY NOT NULL, >>> REQ_TYPE INTEGER NOT NULL, >>> REQ_DATE TIMESTAMP DEFAULT current_timestamp() NOT NULL, >>> CL_ID BIGINT NOT NULL, >>> CONSTRAINT REQUESTS_pk PRIMARY KEY (REQ_ID) >>> ); >>> >>> CREATE INDEX REQUESTS_TYPE_idx >>> ON REQUESTS >>> ( REQ_TYPE ASC ); >>> >>> CREATE INDEX REQUESTS_DATE_idx >>> ON REQUESTS >>> ( REQ_DATE ASC ); >>> >>> ALTER TABLE REQUESTS ADD CONSTRAINT CLIENTS_REQUESTS_fk >>> FOREIGN KEY (CL_ID) >>> REFERENCES CLIENTS (CL_ID) >>> >>> To access database I use FRM Slick, that generates queries >>> >>> for reading something like - select * from requests where req_date >>> between start_date and end_date. >>> for writing something like - insert into requests values >>> (default,tev,ts,clid) >>> >>> In general I need another filter for reading query - on cl_id, so it >>> would be >>> select * from requests where req_date between start_date and end_date >>> and cl_id=clid, >>> >>> but I found it takes 2 times longer to execute the query than the first >>> one. So, after getting a result >>> as List[Request] just use result.filter(r => r.cl_id == clid) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Saturday, April 18, 2015 at 3:36:10 PM UTC+3, sim wrote: >>>> >>>> Hi Noel, >>>> >>>> Nothing special - jdbc:h2:tcp://192.168.1.10:9099/stats >>>> >>>> h2-1.4.187 with default MVStore >>>> >>>> >>>> On Saturday, April 18, 2015 at 12:48:14 PM UTC+3, Noel Grandin wrote: >>>>> >>>>> What does your db URL look like? >>>>> On Fri, 17 Apr 2015 at 20:32, sim <[email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Here is a logger output from my application: >>>>>> >>>>>> 2015-04-17 20:29:07,363 - [INFO] - from application in >>>>>> play-akka.actor.default-dispatcher-24 >>>>>> start to get statistic data - 2015-04-17 20:29:07.363 >>>>>> >>>>>> 2015-04-17 20:29:12,425 - [INFO] - from application in >>>>>> application-akka.actor.default-dispatcher-12 >>>>>> Couldn't save statistic messages - Futures timed out after [5000 >>>>>> milliseconds] >>>>>> >>>>>> 2015-04-17 20:29:17,027 - [INFO] - from application in >>>>>> play-akka.actor.default-dispatcher-24 >>>>>> end to get statistic data - 2015-04-17 20:29:17.027 >>>>>> >>>>>> 2015-04-17 20:29:17,027 - [INFO] - from application in >>>>>> play-akka.actor.default-dispatcher-24 >>>>>> data records for 2015-04-17 - 197873 >>>>>> >>>>>> >>>>>> A thread reads from a table statistics data - 197873 rows (it takes >>>>>> about 10 seconds) >>>>>> Inside this interval another thread is trying to write new data into >>>>>> the table with 5 seconds timeout >>>>>> and gets timeout. >>>>>> >>>>>> So my question - does MVSTORE really support concurrent read/write? >>>>>> >>>>>> Thank you >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
