Does CREATing a DB OPEN it?
I'm still seeing this problem (Database
'PUB_feed_libx_dot_editions_at_gmail...' is currently opened by another
client).
I was able to connect via org.basex.BaseXClient to the database and saw,
via 'SHOW SESSIONS', that the database in question was listed like so:
> SHOW SESSIONS
3 session(s):
- admin [127.0.0.1:35515]:
ts_20120725_dot_213235_dot_723_feed_libx_dot_editions_at_gmail_dot_com_core
- admin [127.0.0.1:37210]
- admin [127.0.0.1:44610]: PUB_feed_libx_dot_editions_at_gmail_dot_com_core
>From the code in Sessions.java/Context.java, I inferred that the db in
question ('PUB_feed_libx_dot_editions_at_gmail_dot_com_core') was the
'current data reference' of session :44610.
How can that be?
As a reminder, I'm not using any 'OPEN' commands...
So I've examined the logs when this db became the 'current' database of
that session, and that, apparently, happened when it was created:
13:58:21.113 [127.0.0.1:44610]:
ts_20120725_dot_135820_dot_723_feed_libx_dot_editions_at_gmail_dot_com_core
CREATE DB PUB_feed_libx_dot_editions_at_gmail_dot_com_core [...]
13:58:21.164 [127.0.0.1:44610]:
PUB_feed_libx_dot_editions_at_gmail_dot_com_core OK 50.95 ms
Is this an undocumented side-effect of 'CREATE DB'?
Is it necessary to follow every 'CREATE DB...' statement with a 'CLOSE'
statement to avoid that the session in which the db was created keeps it
open? It is not mentioned here:
http://docs.basex.org/wiki/Commands#CREATE_DB
If true, I find this rather unusual - and certainly unexpected - it would
be as if a 'CREATE DATABASE' statement in SQL automatically issued a
'USE'... command.
- Godmar
I have added a hint on that in the documentation. Apart from this page, there are several others indicating that a created database will automatically be opened; e.g.: http://docs.basex.org/wiki/Standalone_Mode http://docs.basex.org/wiki/Database_Server If you feel that the documentation is insufficient, it's easy to contribute! You are invited to get an account. Christian
On Thu, Jul 26, 2012 at 7:49 AM, Christian Grün <christian.gruen@gmail.com>wrote:
I have added a hint on that in the documentation. Apart from this page, there are several others indicating that a created database will automatically be opened; e.g.:
http://docs.basex.org/wiki/Standalone_Mode http://docs.basex.org/wiki/Database_Server
http://docs.basex.org/wiki/Database_Server#Create_a_new_database says, for instance: Create a new database Now we will create another database from the xmark.xml<http://files.basex.org/xml/xmark.xml> document. - Create the new database, named 'xmark'.
CREATE DB <http://docs.basex.org/wiki/Commands#CREATE_DATABASE> xmark xmark.xml
- Set the new database xmark as the context:
OPEN <http://docs.basex.org/wiki/Commands#OPEN> xmark
- Now you can easily execute queries on your new database:
XQUERY <http://docs.basex.org/wiki/Commands#XQUERY> //people/person/name
which to many would imply that a CREATE DB must be followed by an 'OPEN', or otherwise your use of the word 'now' doesn't make sense. If you feel that the documentation is insufficient, it's easy to
contribute! You are invited to get an account.
Ok - you want your users to guess what weird design decisions you made, and document them. Unusual request. On a more serious note, I'm wondering why? In our application, we have a connection pool that maintains multiple sessions to the BaseX server for load balancing purposes. This is a commonly used technique I know you're familiar with from SQL databases. With design decisions like yours that create per-session state as side-effects, you've just made this approach much more difficult to implement because each session now has to worry about how its activities might affect other sessions - even in applications where the current context is neither needed nor used. My suggestion would be to rethink that decision and to not open the created database. If you must, provide a 'CREATE DB .... AND OPEN' command for use cases that need the db open after creation. - Godmar
ps: your current design, combined with your locking, also contains an inherent race condition users cannot avoid. Namely, the statements CREATE DB dbname CLOSE are not atomic. As such, if a 'CREATE DB' request for the same dbname arrives in a different session before the created database was closed by the first session, that request will fail with the error I've been getting - and there's no way to avoid that in your design. You'd need a CREATE DB dbname BUT DON"T OPEN IT command to avoid it. Just something to consider... - Godmar
Hello Godmar, While I in principle agree with your criticism about the side effects at the CREATE DB command and I also understand your frustration with a somehow unexpected behaviour, I'd like to remind you that BaseX is an open-source project. If Christian invites you to help to improve the documentation we do not imply that BaseX has to be fixed by its customers. However, as an open-source project we, of course, rely on the contribution of the community and we happily invite everyone to contribute to this project. So in this special case it could be one way to improve the documentation, but of course you are also invited to fix the issue and send a pull request on github. If you can't do this (e.g. because of time restrictions), that is also fine with us. Of course we will always try to fix issues - But we can just do this, if we are aware of them. As you just recently reported this issue, we now know about this issue and try to improve BaseX as a product - but of course you as a community member are also very welcome to help to improve it. Cheers, Dirk On Thu, Jul 26, 2012 at 3:53 PM, Godmar Back <godmar@gmail.com> wrote:
ps: your current design, combined with your locking, also contains an inherent race condition users cannot avoid.
Namely, the statements
CREATE DB dbname CLOSE
are not atomic.
As such, if a 'CREATE DB' request for the same dbname arrives in a different session before the created database was closed by the first session, that request will fail with the error I've been getting - and there's no way to avoid that in your design. You'd need a CREATE DB dbname BUT DON"T OPEN IT command to avoid it.
Just something to consider...
- Godmar
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
I really don't understand your standoffishness, guys. I'm an open source contributor: debugging, testing, commenting. Read Raymond's Bazaar. Some contributors play different roles, depending on the project. I have projects I lead, projects where I code, and in some projects I'm a debugger, tester, and commentator. That's the case with BaseX. You should appreciate that. I'm just glad I eventually figured out what was causing the 'currently opened' errors that led to intermittent (namely, if the request occurred in a different session/connection) failures. - Godmar On Thu, Jul 26, 2012 at 10:16 AM, Dirk Kirsten <dk@basex.org> wrote:
Hello Godmar,
While I in principle agree with your criticism about the side effects at the CREATE DB command and I also understand your frustration with a somehow unexpected behaviour, I'd like to remind you that BaseX is an open-source project. If Christian invites you to help to improve the documentation we do not imply that BaseX has to be fixed by its customers. However, as an open-source project we, of course, rely on the contribution of the community and we happily invite everyone to contribute to this project. So in this special case it could be one way to improve the documentation, but of course you are also invited to fix the issue and send a pull request on github. If you can't do this (e.g. because of time restrictions), that is also fine with us. Of course we will always try to fix issues - But we can just do this, if we are aware of them. As you just recently reported this issue, we now know about this issue and try to improve BaseX as a product - but of course you as a community member are also very welcome to help to improve it.
Cheers, Dirk
On Thu, Jul 26, 2012 at 3:53 PM, Godmar Back <godmar@gmail.com> wrote:
ps: your current design, combined with your locking, also contains an inherent race condition users cannot avoid.
Namely, the statements
CREATE DB dbname CLOSE
are not atomic.
As such, if a 'CREATE DB' request for the same dbname arrives in a different session before the created database was closed by the first session, that request will fail with the error I've been getting - and there's no way to avoid that in your design. You'd need a CREATE DB dbname BUT DON"T OPEN IT command to avoid it.
Just something to consider...
- Godmar
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Godmar, you like to teach, eh? Maybe that's the wrong place ;) Have fun, Christian ___________________________ On Thu, Jul 26, 2012 at 4:49 PM, Godmar Back <godmar@gmail.com> wrote:
I really don't understand your standoffishness, guys.
I'm an open source contributor: debugging, testing, commenting. Read Raymond's Bazaar. Some contributors play different roles, depending on the project. I have projects I lead, projects where I code, and in some projects I'm a debugger, tester, and commentator. That's the case with BaseX. You should appreciate that.
I'm just glad I eventually figured out what was causing the 'currently opened' errors that led to intermittent (namely, if the request occurred in a different session/connection) failures.
- Godmar
On Thu, Jul 26, 2012 at 10:16 AM, Dirk Kirsten <dk@basex.org> wrote:
Hello Godmar,
While I in principle agree with your criticism about the side effects at the CREATE DB command and I also understand your frustration with a somehow unexpected behaviour, I'd like to remind you that BaseX is an open-source project. If Christian invites you to help to improve the documentation we do not imply that BaseX has to be fixed by its customers. However, as an open-source project we, of course, rely on the contribution of the community and we happily invite everyone to contribute to this project. So in this special case it could be one way to improve the documentation, but of course you are also invited to fix the issue and send a pull request on github. If you can't do this (e.g. because of time restrictions), that is also fine with us. Of course we will always try to fix issues - But we can just do this, if we are aware of them. As you just recently reported this issue, we now know about this issue and try to improve BaseX as a product - but of course you as a community member are also very welcome to help to improve it.
Cheers, Dirk
On Thu, Jul 26, 2012 at 3:53 PM, Godmar Back <godmar@gmail.com> wrote:
ps: your current design, combined with your locking, also contains an inherent race condition users cannot avoid.
Namely, the statements
CREATE DB dbname CLOSE
are not atomic.
As such, if a 'CREATE DB' request for the same dbname arrives in a different session before the created database was closed by the first session, that request will fail with the error I've been getting - and there's no way to avoid that in your design. You'd need a CREATE DB dbname BUT DON"T OPEN IT command to avoid it.
Just something to consider...
- Godmar
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
participants (3)
-
Christian Grün -
Dirk Kirsten -
Godmar Back