search

lbehnke / h2database

Automatically exported from code.google.com/p/h2database
0 stars 0 forks source link

NullPointerException org.h2.store.PageLog.removeUntil #171

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
We have text data stored into CLOB using setString. When just insert this
text, no problem occurs. Only in our application, it throws an exception.

Note: ConnectionPool used in application

It seems that the session is null?

What version of the product are you using? On what operating system, file
system, and virtual machine?
1.2.9 on WinXP
1.2.7 on WinXP
Both have the same problem

Do you know a workaround?
No.

In your view, is this a defect or a feature request?
Defect.

Please provide any additional information below.

02-26 15:43:04 pageStore: pageOut.storePage [3549] stream data pos:1222
remaining:826
02-26 15:43:04 pageStore: pageOut.storePage fill 3549
02-26 15:43:04 pageStore: switchLog
02-26 15:43:04 pageStore: log.removeUntil 48
02-26 15:43:04 jdbc[2]: SQLException

General error: "java.lang.NullPointerException" [50000-129]
    at org.h2.message.DbException.getJdbcSQLException(DbException.java:317)
    at org.h2.message.DbException.get(DbException.java:157)
    at org.h2.message.DbException.convert(DbException.java:285)
    at org.h2.message.DbException.toSQLException(DbException.java:253)
    at org.h2.message.TraceObject.logAndConvert(TraceObject.java:387)
    at
org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:132)

Caused by: java.lang.NullPointerException
    at org.h2.store.PageLog.removeUntil(PageLog.java:686)
    at org.h2.store.PageLog.removeUntil(PageLog.java:663)
    at org.h2.store.PageStore.switchLog(PageStore.java:563)
    at org.h2.store.PageStore.checkpoint(PageStore.java:339)
    at org.h2.store.PageStore.commit(PageStore.java:1109)
    at org.h2.engine.Database.commit(Database.java:1667)
    at org.h2.engine.Session.commit(Session.java:450)
    at org.h2.command.Command.stop(Command.java:167)
    at org.h2.command.Command.executeUpdate(Command.java:243)
    at
org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.ja
va:141)
    at
org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:127)
    ... 11 more

Original issue reported on code.google.com by schuen...@gmail.com on 26 Feb 2010 at 2:51

GoogleCodeExporter commented 9 years ago 
Hi,

How large is the text exactly? Did you try using CLOB?

In any case, this looks like a serious problem. I have a few questions:

- Is it possible to reproduce this problem using a fresh database
    (sometimes, or always)?
- What is your database URL?
- Did you use multiple connections?
- Do you use temporary tables?
- With which version of H2 was this database created?
    You can find it out using:
    select * from information_schema.settings where name='CREATE_BUILD'
    or have a look in the SQL script created by the recover tool.
- Did the application run out of memory (once, or multiple times)?
- Do you use any settings or special features (for example cache settings,
    two phase commit, linked tables)?
- Do you use any H2-specific system properties?
- Is the application multi-threaded?
- How did you start the Java process (java -Xmx... and so on)?
- How big is the database (file sizes)?
- Is the database usually closed normally, or is process terminated
    forcefully or the computer switched off?
- Are there any other exceptions (maybe in the .trace.db file)?
    Could you send them please?
- Do you still have any .trace.db files, and if yes could you send them?
- Could you send the .h2.db file where this exception occurs?

Regards,
Thomas

Original comment by thomas.t...@gmail.com on 26 Feb 2010 at 3:07

GoogleCodeExporter commented 9 years ago 
How large is the text exactly? Did you try using CLOB?

The text is "only" about 30kb, we tried using CLOB. But still the same problem.

In any case, this looks like a serious problem. I have a few questions:

- Is it possible to reproduce this problem using a fresh database
    (sometimes, or always)?

We always use a fresh database and the problem occurs always.

- What is your database URL?

pool = JdbcConnectionPool.create("jdbc:h2:" + dbname + ";IFEXISTS=TRUE", "xxx", 
"xxx");

conn = this.pool.getConnection();

- Did you use multiple connections?

We use the connection from the connection pool. We have several databases and 
each
one get a connection pool.

- Do you use temporary tables?

No

- With which version of H2 was this database created?

1.2.9 latest release

- Did the application run out of memory (once, or multiple times)?

No. Fresh database, no out of memory.

- Do you use any settings or special features (for example cache settings,
    two phase commit, linked tables)?

No.

- Do you use any H2-specific system properties?

No.

- Is the application multi-threaded?

Yes.

- How did you start the Java process (java -Xmx... and so on)?

start in eclipse or using java -Xmx...

- How big is the database (file sizes)?

9 MB when the exception throws.

- Is the database usually closed normally, or is process terminated
    forcefully or the computer switched off?

The exception terminated the process forcefully. But we always start with a 
fresh
database.

- Are there any other exceptions (maybe in the .trace.db file)?
    Could you send them please?

There were some Unique index or primary key violations. However, we caught these
exceptions.

Original comment by schuen...@gmail.com on 26 Feb 2010 at 3:28

GoogleCodeExporter commented 9 years ago 
Hi,

I'm sorry, I don't know what the problem could be right now. Could you send me 
the
application? Or if not, could you append ;TRACE_LEVEL_FILE=3 to the database 
URL and
send me the .trace.db file?

Regards,
Thomas

Original comment by thomas.t...@gmail.com on 26 Feb 2010 at 3:53

GoogleCodeExporter commented 9 years ago 
Hi,

the problem occurred when there is still something "remaining"...

pageStore: pageOut.storePage [3549] stream data pos:1222 remaining:826
pageStore: pageOut.storePage fill 3549
pageStore: switchLog
pageStore: log.removeUntil 48

Original comment by schuen...@gmail.com on 26 Feb 2010 at 4:33

GoogleCodeExporter commented 9 years ago 
and at end, it could not close the database...

02-26 17:30:24 pageStore: log commit s:2
02-26 17:30:24 pageStore: checkpoint
02-26 17:30:24 pageStore: pageOut.storePage [4291] stream data pos:14 
remaining:2034
02-26 17:30:24 pageStore: pageOut.storePage fill 4291
02-26 17:30:24 pageStore: switchLog
02-26 17:30:24 pageStore: log.removeUntil 46
02-26 17:30:24 database: Could not close the database
java.lang.NullPointerException
    at org.h2.store.PageLog.removeUntil(PageLog.java:686)
    at org.h2.store.PageLog.removeUntil(PageLog.java:663)
    at org.h2.store.PageStore.switchLog(PageStore.java:563)
    at org.h2.store.PageStore.checkpoint(PageStore.java:339)
    at org.h2.store.PageStore.commit(PageStore.java:1109)
    at org.h2.engine.Database.commit(Database.java:1667)
    at org.h2.engine.Session.rollback(Session.java:508)
    at org.h2.engine.Database.close(Database.java:996)
    at org.h2.engine.DatabaseCloser.run(DatabaseCloser.java:80)

Original comment by schuen...@gmail.com on 26 Feb 2010 at 4:38

GoogleCodeExporter commented 9 years ago 
Hi,

> when there is still something "remaining"...

There is almost always something remaining :-)

Could you append ;TRACE_LEVEL_FILE=3 to the database URL (actually you already 
did
that, right?), and then upload the complete .trace.db file? From a fresh 
database if
possible, so that I can reproduce the problem. Here, or if not possible, 
somewhere
else for example http://rapidshare.com/ ?

Regards,
Thomas

Original comment by thomas.t...@gmail.com on 26 Feb 2010 at 4:45

GoogleCodeExporter commented 9 years ago 
Hi,

it seems that we have found the problem. we have initialized the database twice 
:-(

sorry.

happy weekend

Original comment by schuen...@gmail.com on 26 Feb 2010 at 5:46

GoogleCodeExporter commented 9 years ago 
I don't understand... Did you disable the database file lock?

Original comment by thomas.t...@gmail.com on 26 Feb 2010 at 8:27

GoogleCodeExporter commented 9 years ago 
i mean we may have created multiple connections to the database..

Now we have only one connection and it seems to work..

Original comment by schuen...@gmail.com on 26 Feb 2010 at 8:32

GoogleCodeExporter commented 9 years ago 
> we may have created multiple connections to the database..

That should not be a problem.

Could you append ;TRACE_LEVEL_FILE=3 to the database URL (actually you already 
did
that, right?), and then upload the complete .trace.db file? From a fresh 
database if
possible, so that I can reproduce the problem. Here, or if not possible, 
somewhere
else for example http://rapidshare.com/ ?

Regards,
Thomas

Original comment by thomas.t...@gmail.com on 27 Feb 2010 at 8:13

GoogleCodeExporter commented 9 years ago 
sorry Thomas, we cannot send you the db file. Let me check if i can reproduce 
the
problem with dummy data. 

Regards,
Schuen

Original comment by schuen...@gmail.com on 27 Feb 2010 at 10:13

GoogleCodeExporter commented 9 years ago 
so thomas, it seems that we can reproduce the problem.

If the lock file is deleted during processing, the exception occurs when the db 
file
becomes about 8-12 MB..

see attachment.

Original comment by schuen...@gmail.com on 28 Feb 2010 at 10:57

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks a lot! I can reproduce the problem now.

Your application overwrites the contents of the database file while the 
database is
in use: First, the Initializer class overwrites the database (copies the 
database
file from database.h2.db to database1.h2.db), then it opens a connection. Then, 
the
database file is again overwritten in the initializer of the class ThreadDo.
File.delete() returns false, but your application doesn't check that.

> If the lock file is deleted

I can reproduce the problem without deleting the .lock.db file.

I will add a feature request for "Use JDK 1.4 file locking for the database 
file".

Original comment by thomas.t...@gmail.com on 28 Feb 2010 at 12:27