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.comwrote:
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.xmlhttp://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
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Dirk Kirsten -
Godmar Back