You are right. After some extensive debug, *is the use of a Pool
Manager*(either internal or external do Datanucleus core) that is causing the
problem.
Can't find any other method than CLOSE (and since DN takes care of the pool
initialization, i believe it's out of my control)
DB_CLOSE_DELAY,
Thomas, i was looking at the H2 sources and i believe that you monitor the
file LOCK with a daemon Thread. My question is: HOW do you create the File
Lock? Using the java native TEMP file creator?
*TEST CASE*:
File lock=new File(DATABASE_NAME+".lock.db");
Cl
Hi,
H2 doesn't "miss the unlock". I'm sure this is not a problem in the
database. It is clearly a problem on your side.
Regards,
Thomas
On Sat, Nov 2, 2013 at 4:27 PM, marcolopes wrote:
> Thomas, this only happens if the user misses the "login"...
>
> 1) Backup the **closed** database
> 2) Lo
Thomas, this only happens if the user misses the "login"...
1) Backup the **closed** database
2) Login is attempted and fails
3) Database is closed (well, i issue the datanucleus PFM.close that shoud
close ALL connections / poolmanager)
4) Back to step 1 - and that is where it might be problemati
Hi,
Copying the database file while the database is open is not a good idea. It
will work in most cases, but not in all cases (for example if the
transaction log is rolled over while the backup is in progress). When it
doesn't work, the database will be corrupt. Don't blame us for that.
If you wa
Then it sounds like the problem is with datanucleus not closing it's
connection to the db. Perhaps it needs some special call or parameter to
tell it that?
Or are you using db_close_delay in your db URL? Which would also cause the
db to not close when the last connection is closed.
Or maybe you are
Thomas, i know what's going on...
1) The first backup is made
2) The database is opened (i'm using Datanucleus persistence, so, no
control from my code)
3) A database LOCK file is created
4) I close the "Persistence Manager Factory" but the LOCK file is not
released... (it is released only when
Hi,
I don't know what you do exactly, but I can not reproduce it. Could you
provide a simple, reproducible test case? My test case is: I create a
database "test". After that there is a file called "test.h2.db". Then I
backup this file 4 times, and that works, and no .lock.db files are created.
*p
The database is **closed**!
The problem is that, on the first backup execution a LOCK is created... and
all subsequent backup attempts fail.
On Friday, November 1, 2013 5:52:55 PM UTC, Thomas Mueller wrote:
>
> Hi,
>
> What do you try to do? If the database is open, you should probably use
> th
Hi,
What do you try to do? If the database is open, you should probably use the
BACKUP SQL statement, not the Backup standalone tool.
Regards,
Thomas
On Fri, Nov 1, 2013 at 6:39 PM, marcolopes wrote:
> I don't really understand the behavior of this parameter on the *
> Backup.execute* method
I don't really understand the behavior of this parameter on the *
Backup.execute* method.
I thought it would disable the possible "log info", but, inspecting the
code, it goes beyond that.
The problem with the current approach is: if quiet=false, there is an
attempt to LOCK the database... and
11 matches
Mail list logo
