Hi,
> 2) My second issue is that of a long start up time
I guess there is a connection with an open transaction (an uncommitted
change) that is blocking the transaction log to shrink. Or multiple
connections. This would also explain why it gets slower over time. To find
out, you could use:
jps -l (to get the process id)
jmap -histo <pid>
This will list the live objects. The live connections are JdbcConnection.
Then you can use the trace feature to find out which connection stays open.
To do that, append ;trace_level_file=3 to the database URL - all JDBC API
calls are then logged in the .trace.db file.
The database actually "knows" which connection (well... session) has an
open transaction. Possibly it should log the session id for such cases. I
will add a feature request: "Long running transactions: log session id when
detected." - But using jmap -histo and "trace_level_file=3" should solve
the problem as well.
> The documentation states that if one enables MVCC then the
> transaction log must fit in memory.
Only the undo log (the list of uncommitted changes).
Checkpoint shouldn't be required (it is automatic). If you have a simple,
standalone test case where opening a database takes a very long time please
tell me.
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.
