Hi Thomas,
  I've tried to create a test case that causes the failure, but can
only cause the failure by debugging the code within eclipse, so its
not repeatable.  What I've found is that if I have 2 connections to a
database, each executing a different query against a single view, and
the 2 queries use a different number of the columns included within
one of the indexes, I can cause it to fail.  Since the getCost()
method of ViewIndex overwrites the columns variable, the 2 threads
each execute their query, and if one thread is already within the
getCost() method, and has made it down into the "for (int i = 0; i <
len; i++) " loop, and a second thread enters the getCost(), with a
smaller number of columns, that second thread can set the columns
variable to a smaller array, while the first thread is still expecting
it to be of the larger size.  Shouldn't the columns array that is used
within the getCost method be a local variable to that method?  Let me
know if I need to explain this better.

Matt



CREATE TABLE STATEMENTS ( COLUMN1 BIGINT,COLUMN2 BIGINT,COLUMN3
BIGINT, COLUMN4 BIGINT, COMMITTED BIGINT,END BIGINT)
CREATE INDEX ST1 ON STATEMENTS (COLUMN1,COLUMN2,COLUMN3)

CREATE TABLE STATEMENTS2 ( COLUMN1 BIGINT,COLUMN2 BIGINT,COLUMN3
BIGINT, COLUMN4 BIGINT)
CREATE INDEX ST2 ON STATEMENTS2 (COLUMN1,COLUMN2,COLUMN3)

CREATE VIEW STATEMENTS_VIEW(COLUMN1,COLUMN2,COLUMN3,COLUMN4) AS
                    SELECT COLUMN1,COLUMN2,COLUMN3,COLUMN4,COMMITTED FROM 
STATEMENTS
WHERE COMMITTED<=0 AND END IS NULL
                    UNION
                   SELECT COLUMN1,COLUMN2,COLUMN3,COLUMN4,COMMITTED
FROM STATEMENTS2 WHERE COMMITTED<=0

Query1:
SELECT DISTINCT tp1.COLUMN2,tp2.COLUMN2  FROM STATEMENTS_VIEW
tp1,STATEMENTS_VIEW tp2 WHERE tp1.COLUMN1=tp2.COLUMN1 AND
TP1.COLUMN2=TP2.COLUMN2
Query2:
SELECT DISTINCT tp1.COLUMN2,tp1.COLUMN3,tp2.COLUMN2  FROM
STATEMENTS_VIEW tp1,STATEMENTS_VIEW tp2 WHERE tp1.COLUMN1=tp2.COLUMN1


On Jun 15, 2:52 pm, Thomas Mueller <thomas.tom.muel...@gmail.com>
wrote:
> Hi,
>
> > I'm not sure if this the same exception that others were getting
>
> No, it's a different stack trace.
>
> > If I can recreate a test case I'll submit that
>
> That would be great!
>
> > but we can hope it will be something obvious.
>
> I'm sorry, I don't understand currently how this exception could
> occur. I think I need a test case.
>
> 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-database@googlegroups.com
To unsubscribe from this group, send email to 
h2-database+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/h2-database?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to