View Issue Details

IDProjectCategoryView StatusLast Update
0003324VALENTINA SERVERDatabasepublic2008-08-16 06:51
ReporterDanny LewkinAssigned ToRuslan Zasukhin 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version4.0 
Target VersionFixed in Version4.0 
Summary0003324: unregister db
DescriptionVServer embedded on linux 3.6b26, VStudio on mac osx
If I unregister a db with vStudio, it is still ACCESSABLE!
It doesn't show in VStudio (even after restart VStudio and Reconnect to server), but I can still access it through my application.
When I restart the SERVER, then it's really unregistered and I can not access it anymore...
TagsNo tags attached.

Relationships

parent of 0003345 resolvedIvan Smahin VCOMPONENT-VKERNEL "DROP CONNECTIONS FOR db_name" syntax for server admin purpose 
parent of 0003346 resolvedIvan Smahin VCOMPONENT-VKERNEL [NEW] SQL command "REGISTER/UNREGISTER DATABASE db_name". 

Activities

Ruslan Zasukhin

Ruslan Zasukhin

2008-07-30 22:56

administrator   ~0003724

You have info if this happens only linux?
I assume not only.
Ivan please try reproduce it.
Danny Lewkin

Danny Lewkin

2008-07-30 23:12

reporter   ~0003725

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...
Ivan Smahin

Ivan Smahin

2008-08-04 01:02

manager   ~0003730

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.
Danny Lewkin

Danny Lewkin

2008-08-05 04:30

reporter   ~0003733

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?
Ivan Smahin

Ivan Smahin

2008-08-05 04:59

manager   ~0003734

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
Danny Lewkin

Danny Lewkin

2008-08-06 23:12

reporter   ~0003740

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
Ivan Smahin

Ivan Smahin

2008-08-09 23:41

manager   ~0003761

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.

Issue History

Date Modified Username Field Change
2008-07-30 22:34 Danny Lewkin New Issue
2008-07-30 22:38 Ruslan Zasukhin Project VCOMPONENT-VKERNEL => VALENTINA SERVER
2008-07-30 22:56 Ruslan Zasukhin Note Added: 0003724
2008-07-30 23:12 Danny Lewkin Note Added: 0003725
2008-08-04 01:02 Ivan Smahin Note Added: 0003730
2008-08-05 04:30 Danny Lewkin Note Added: 0003733
2008-08-05 04:59 Ivan Smahin Note Added: 0003734
2008-08-06 23:12 Danny Lewkin Note Added: 0003740
2008-08-09 23:41 Ivan Smahin Note Added: 0003761
2008-08-09 23:47 Ivan Smahin Relationship added parent of 0003345
2008-08-13 11:18 Ivan Smahin Relationship added parent of 0003346
2008-08-16 06:51 Ruslan Zasukhin Status new => resolved
2008-08-16 06:51 Ruslan Zasukhin Fixed in Version => 3.6
2008-08-16 06:51 Ruslan Zasukhin Resolution open => fixed
2008-08-16 06:51 Ruslan Zasukhin Assigned To => Ruslan Zasukhin