Startup/shutdown we largely assume is the responsibility of some higher level
component.
For backup/restore, what we have is SET EXCLUSIVE
http://h2database.com/html/commands.html#set_exclusive
We have basic infrastructure such code could be built-on, the admin database stuff, which was,
You can't go EXCLUSIVE and then delete a database.
But perhaps you mean overwrite, in which case this flow should be fine.
--
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
@Noel Grandin-
Yeah, that higher-level component is what we are writing. Maybe we don't
need to call shutdown to flush all the buffers?
Q: Will this flow maintain data and transactional consistency?
1. Management-Connection: Create database (and start)
2. Client-Connections: do SQL stuff
3.
Got it, we'll give that a whirl without the delete for backup/restore.
The thought on doing the delete database ahead of restore was to be sure to
clear out any swapped temp files from large queries, etc. Looks like the
EXCLUSIVE mode should clean all that up for us.
Question:
For the
We are working through maintenance scenarios, and have hit a roadblock on
blocking client connections and re-starting a shutdown database. This is
problematic when clients use pools and auto-reconnect.
Scenarios:
1. Blocking new clients from connecting during backup / restore or export /
