I hope you can help me with what's probably a basic question, but one I haven't
found an answer to elsewhere.
I haven't used Derby extensively, but I do have experience with multithreaded
applications with MySQL. I've noticed some interesting but surprising behavior
with Derby I was hoping I
Ron,
Even though I do not have a solution for your problem, I just wanted
to let the community know I ran into the same issue. Essentially, I've
Tomcat connection pool (DBCP) with 20 max connections connecting to
Embedded Derby. Under heavy load (or during load testing), inserting
and deleting con
Sai,
When I have large numbers of inserts happening that I can't batch, I end up
funneling them through a method that enforces throttling with a Semaphore, so
something like:
// 10 permits, fair set to true
Semaphore throttle = new Semaphore(10, true);
void insertMethod(/* whatever params I ne
What isolation level are you using? If you just use read committed
isolation level (default in JDBC/Derby) and a read only result set
when you iterate, locks should not be kept on the records you have
already read.
http://db.apache.org/derby/docs/10.5/devguide/cdevconcepts30291.html
Dag
I've tried a couple of different isolation levels, specifically read committed
and repeatable read since they seemed to be most applicable.
In my code as it is written today I don't use transactions. When I've enabled
transactions for the thread iterating over resultsets, with various isolatio
Ron,
Thanks for the hint. I'll have to try it out. Unfortunately, I cannot
batch the inserts due to our app requirements. But I'm pretty sure I
did try it with as little as 5 threads constantly inserting and
deleting records and was able to produce the lock timeout errors. Our
app does not normall
The specific exception I'm getting is:
org.apache.derby.client.am.SqlException: A lock could not be obtained within
the time requested
Derby can be configured to provide a lot of additional
information which can help you understand why you are
getting lock timeouts and deadlocks in your applic
Thanks Bryan, I'm looking into doing a bit more debugging, though I found a
solution that throttles my activity sufficiently while I work on other
problems. Unfortunately I don't have a lot of time to devote to this
particular issue, I was just hoping that perhaps there was something obvious I
Ronald Rudy writes:
> In my code as it is written today I don't use transactions. When
> I've enabled transactions for the thread iterating over resultsets,
> with various isolations, it didn't seem to help - it either blocked
> out others or never started.
Derby is always transactional, so ev
On Jan 29, 2010, at 11:33:28 AM, Dag H. Wanvik wrote:
> Derby is always transactional, so even with autocommit, when you open
> a read-only result set for iterating over it, any read locks it sets
> for a row would block another connection trying to modify that row
> (Update or delete). If you use
10 matches
Mail list logo
