They are basically 1024 unicode chars tops. So keeping them in memory should be ok.
> Integer.MAXVALUE I'll try to use VARCHAR(1024); but > CLOB > should be used for documents and texts with arbitrary size such as XML > or HTML documents, text files, or memo fields of unlimited size. > VARCHAR should be used for text with relatively short average size > (for example shorter than 200 characters) On Friday, March 1, 2013 3:02:21 AM UTC+2, Kartweel wrote: > > Side note: LOCK_MODE has no effect with MVCC. > > There is also a FOR UPDATE bug with LOBS in MVCC. My guess is these issues > won't get fixed unless you submit a patch as the devs are working on a new > storage backend which should solve all the issues. > > You could try BINARY? I think it stores the object in memory when you > query them? SO make sure you got enough memory to hold all your big > objects. Integer.MAXVALUE is 2GB of data if I'm not mistaken?. How big are > your BLOBS? > > > > On 1/03/2013 8:30 AM, Nick99 wrote: > > Hello, > > Any plans for the fix/workaround? > > I can only think of some pretty messy workarounds like moving my CLOB > fields to > a) just VARCHAR(*255*) /though the docs say *The maximum precision is > Integer.MAX_VALUE<http://www.h2database.com/html/datatypes.html#varchar_type> > */ > b) or to BLOB (may behave the same way as CLOB) > c) or to BINARY (looks promising). > > > > On Tuesday, December 4, 2012 6:59:08 PM UTC+2, Nick99 wrote: >> >> It seems the problem is with MVCC. >> >> The test is not failing for 30s on my system >> with: "jdbc:h2:db/test01;MVCC=*FALSE* >> ;MULTI_THREADED=0;LOCK_MODE=3;LOCK_TIMEOUT=20000;" >> >> All isolation levels fail for (in the 1-5s >> timeframe): "jdbc:h2:db/test01;MVCC=*TRUE;* >> MULTI_THREADED=0;LOCK_MODE=3;LOCK_TIMEOUT=20000;" >> Connection.TRANSACTION_READ_UNCOMMITTED >> Connection.TRANSACTION_READ_COMMITTED >> Connection.TRANSACTION_REPEATABLE_READ >> Connection.TRANSACTION_SERIALIZABLE >> >> On Tuesday, December 4, 2012 11:01:37 AM U >> TC+2, Noel Grandin wrote: >>> >>> Hmmm, I think what is happening here is that when in MVCC mode with >>> transaction isolation level TRANSACTION_READ_COMMITTED, the session is >>> somehow seeing LOB entries that have already been deleted. >>> >>> Thomas, does that ring any bells? >>> >>> I've been through the code paths that end up in LobStorage, but I can't >>> see any obvious problems. >>> >>> On 2012-12-03 09:58, Noel Grandin wrote: >>> > Nice work on creating the test case! >>> > >>> > Interesting, this is a genuine bug somewhere in the LOB code, and it >>> > manifests even with MVCC=false. >>> > >>> > The only short-term fix I can see is to set your transaction isolation >>> > to TRANSACTION_REPEATABLE_READ. >>> > >>> > Thomas, I further reduced the test-case, and I'm including it here. >>> > Note that (for me) it did not fail every single time. I normally let >>> > it run for about 15 seconds, and then terminate and try again. >>> > I get a failure rate of about 50%. >>> > >>> >>> -- > 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] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/h2-database?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
