Hi Noel,
I replaced the custom legacy /DataSource/ dedicated to connection pooling
with /org.h2.jdbcx.JdbcDataSource/, and logged the contents of
/INFORMATION_SCHEMA.SESSIONS/ every time a table copy is completed. I also
disabled the insertion of indexes and foreign keys and replaced /DROP ALL
OBJECTS/ with a single /DROP/ statement for every single table.
The db size still *continues to increase* (please note I had to switch to
the svn trunk contents in order to get the additional metadata column, so
these tests may be eventually affected by regressions or behavior changes).

Anyway I noticed some things that seem strange to me: I'll try to give you
as much detailed info I can.

Issue 1

The /issue_log _size/ is always 0, but after the 3rd table (hence the 3rd
time I query the metadata table), /INFORMATION_SCHEMA.SESSIONS/ contents
seems cached (don't change anymore for that import session).

Here you are the contents from /INFORMATION_SCHEMA.SESSIONS/ (where the
columns are /ID         |USER_NAME      |SESSION_START          |STATEMENT  
|STATEMENT_START        |UNDO_LOG_SIZE/)

*with a pooling DataSource*


Issue 2

I also have to say that before disabling connection pooling there was also
another issue: at the end of the 1st import I got an additional session with
a null statement. From then on, that session and the metadata query one
remained unchanged on the while 2nd import (within the same jvm instance)

*without a pooling DataSource*



Issue 3

The 2nd import generates in the trace file a bunch of error messages I never
noticed before disabling connection pooling. I paste here some of them








Since they always seem related to connection closing methods, I suspect they
were not triggered at all with connection pooling enabled, but their cause
could lead to other side-effects (such as db size increase?).

Cheers
Davide


Noel Grandin wrote
> On 2013-08-19 09:44, davide.cavestro wrote:
>> didn't notice) and eventually debug. It would indeed be very useful if I
>> had
>> some sort of API (even H2 internal) exposing the connection transactional
>> status (pending statements and so on)./
>>
> 
> I've added an UNDO_LOG_SIZE column to the INFORMATION_SCHEMA.SESSIONS 
> metadata table.
> That should allow you to monitor sessions and see which ones are going 
> rogue.
> 
> 
> -- 
> 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 

> h2-database+unsubscribe@

> .
> To post to this group, send email to 

> h2-database@

> .
> Visit this group at http://groups.google.com/group/h2-database.
> For more options, visit https://groups.google.com/groups/opt_out.





--
View this message in context: 
http://h2-database.66688.n3.nabble.com/h2-Continuous-Increase-in-H2-db-size-after-dropping-and-loading-same-data-repeatedly-tp4026836p4027175.html
Sent from the H2 Database mailing list archive at Nabble.com.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to