 |
You have info if this happens only linux? I assume not only. Ivan please try reproduce it. |
 |
I tested it on mac osx, VServer version 3.5.2, and it does not happen. I can no longer access db when it's unregistered... What I did notice, for the second time now, is that vstudio crashes after a few minutes after unregistering db... Happened already twice... |
 |
So I assume it is following scenario: 1. Run some your application which is open and use server database. 2. Run vStudio and unregister the database from the server. This vStudio instance (and any other) has no access to the database anymore. 3. Switch to your application - it is still working with that database. Close app. 4. Run app. again - no access to the db. Right? If so - it is predictable results. Unregistered database is still accessible for the current connections and blocks new ones. |
|
|
Hi Ivan, I did this 2 times today: 1. unregister db 2. DELETE DATABASE FILES FROM FOLDER (as root, with sudo nautilus in terminal) 3. copied new database files 4. register the db again 5. Still seeing OLD values in VStudio..... 6. Killed VServer 7. Restarted VServer 8. Now I see new values with vstudio... I don't know enough about linux to exactly pin point what the hell is goeing on, can't understand it... Is it possible that vserver keeps a copy af the db in memory? |
|
|
Not exactly the copy of database but some cached part of it. So it would be possible to get some values without disk-reading at all. Attempting to replace databases on working server is not good idea. In fact you should unregister database, stop the server, copy new database in place and start the server again. Or without restarting server: 1. Unregister database (no new connection can access it) 2. Make sure no connections to the database exists 3. Copy new files 4. Register database |
|
|
Ivan, I think it really must be possible to replace the db on a WORKING server. If there are several db's running on server, and people are connected and working on them, it would be very unlogical and bad, to disconnect hem all by stopping the server, because I have to change 1 db... Even so, I understand what you're saying (if there are open connections...), but if there are connections open to the db I want to replace, shouldn't the FILES be LOCKED??? If I unregister the db now, I can DELETE the files, replace them and register them again! So, how can I know that I'm still working with old data?? Is it just me, or does this sound very unlogical?? 'Cached part' of it...? So, if I understand this correctly, the people working with that 'cached part' will work with old data, and people working on a different part will see new data?? If this is the case, then it is totally UNACCEPTABLE... I suggest 2 solutions: 1. Disconnect all connections to that db that is unregistered (also the existing ones), and allow to replace it, register it again, and work with new data (so old cached data is gone). This is my prefferable solution. or 2. Don't allow to delete the database files, keep them locked, and don't allow replacing them. I think this is different on mac and win, where I actually can't delete the files... (on mac I'm sure, on windows I'm not sure...) Only in that way, we can be sure that everone is working with the same data, and there will be no misunderstanding with which data people are working. Greetz, Danny |
|
|
Danny, The scenario I described above is still the way. You can use vStudio to obtain the connection list which used the unregister database and manually turn them off. On the other hand we are going to implement some SQL syntax for admin purpose - something like "DROP CONNECTIONS FOR db_name" So you will be able: 1. Unregister database 2. Issue that query On this stage you have a guarantee that no connection uses the unregistered database anymore. So you can do drop, replace or anything for that db. |
- Anonymous
