Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 11 total |
Problem with blob fields on network |
Fri, Jul 6 2007 7:31 AM | Permanent Link |
Igor Colovic | Hi.
The application and data is located on the network share. The first user who starts the application opens it quickly. The all the other users have to wait a long time for application to open. After second user opens the application, the first application is slow as the second one. The problem is with table witch have to be shown in DBGrid and it contains one blob field. I have watched network traffic (server is samba) and the problem is in reading file. I know that it is not samba problem because same thing is with windows server. The first run of the application is reading blob file in chunks of 32768 bytes. The second run of the application is reading blob file in chunks of 64 bytes (witch is BLOB block size). Why this difference. Is is 512 times slower. If I close any application, after some time running application is faster. I have tried to change MaxTableDataBufferSize, MaxTableDataBufferCount, MaxTableIndexBufferSize, MaxTableIndexBufferCount, MaxTableBlobBufferSize, MaxTableBlobBufferCount. |
Fri, Jul 6 2007 12:44 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Igor,
<< I have watched network traffic (server is samba) and the problem is in reading file. I know that it is not samba problem because same thing is with windows server. >> It's opportunistic locking. See here: http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=58854&page=1#msg58854 -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jul 10 2007 6:59 AM | Permanent Link |
Igor Colovic | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
Igor, It's opportunistic locking. See here: http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=58854&page=1#msg58854 Another thing. DBISAM is not honoring TDBISAMTable And TDBISAMQuery ReadOnly property. File is opened ReadWrite regardless of ReadOnly property settings. This is not OK. I know that I can set files ReadOnly attribute but in my application I sometimes write to database. So I do not want to change attributes of files. BDE and All the other replacements honor this property and open file according to this property. This way I can speed reading of files regardless of their attributes just by setting ReadOnly to true. |
Tue, Jul 10 2007 11:57 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Igor,
<< Another thing. DBISAM is not honoring TDBISAMTable And TDBISAMQuery ReadOnly property. File is opened ReadWrite regardless of ReadOnly property settings. This is not OK. I know that I can set files ReadOnly attribute but in my application I sometimes write to database. >> Both of these components are simply cursors on the underlying table(s). This is not the same as opening the physical table itself. In other words, you can have one TDBISAMTable with ReadOnly set to True and another one with ReadOnly set to False. Since DBISAM only physically opens a table once per process, it has to open it read-write because there's no guarantee that all table cursors in a process will want the same read-only or read-write access. << So I do not want to change attributes of files. BDE and All the other replacements honor this property and open file according to this property. This way I can speed reading of files regardless of their attributes just by setting ReadOnly to true. >> With DBISAM, you're going to have change the attributes of the files if you want the benefit of the improved read-only performance. It's the only way that DBISAM can guarantee that another session can't modify the tables, thus allowing DBISAM to relax its locking and change detection. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jul 11 2007 4:50 AM | Permanent Link |
Igor Colovic | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
<<With DBISAM, you're going to have change the attributes of the files if you want the benefit of the improved read-only performance. It's the only way that DBISAM can guarantee that another session can't modify the tables, thus allowing DBISAM to relax its locking and change detection.>> Ok. But can you add some property or procedure. Something like ForceReadOnly or OpenReadOnly and let programmer worry about everything else. This would be a great benefit. |
Wed, Jul 11 2007 7:40 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Igor,
<< Ok. But can you add some property or procedure. Something like ForceReadOnly or OpenReadOnly and let programmer worry about everything else. >> Not on an individual TDBISAMTable or TDBISAMQuery level, no. It's the wrong place to put it. We could potentially put something at the session level, but that would mean that all access would be read-only. The only legitimate place to put something like this would be in the table itself, but unfortunately that is a catch-22 because we would need to open the table first in order to determine whether the table should be opened read-only. However, this is something that we could add to our other ElevateDB product due to the fact table metadata is stored separate from the tables themselves in the database catalog, and so could be marked as read-only in the catalog. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Jul 13 2007 4:25 AM | Permanent Link |
Igor Colovic | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
<<Not on an individual TDBISAMTable or TDBISAMQuery level, no. It's the wrong place to put it. We could potentially put something at the session level, but that would mean that all access would be read-only. The only legitimate place to put something like this would be in the table itself, but unfortunately that is a catch-22 because we would need to open the table first in order to determine whether the table should be opened read-only.>> Putting it in session would be Ok. You could have separate database and session components for read-only And read-write tables. Later on if you want to write to one of read-only tables, you could close it, reassign session and database and open it read-write. Or the other way around. I know that in this case same table could be opened in both sessions, but that is something programmers should worry about, not You. <<However, this is something that we could add to our other ElevateDB product due to the fact table metadata is stored separate from the tables themselves in the database catalog, and so could be marked as read-only in the catalog.>> I am not using ElevateDB, but this would be great. I suppose it would be possible to change this read-only status from the code? |
Fri, Jul 13 2007 4:39 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Igor,
<< Putting it in session would be Ok. You could have separate database and session components for read-only And read-write tables. Later on if you want to write to one of read-only tables, you could close it, reassign session and database and open it read-write. Or the other way around. >> Actually, scratch what I said. We couldn't even do it at the session level. The issue is that *all* sessions must know for a fact that no other session can write to the tables in order to turn off the locking and change detection and improve performance. The only way to do so is via the table metadata or via the OS. << I am not using ElevateDB, but this would be great. I suppose it would be possible to change this read-only status from the code? >> Yes, but it would require altering the table, which would require exclusive access to the table. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Jul 16 2007 5:02 AM | Permanent Link |
Igor Colovic | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
<<Actually, scratch what I said. We couldn't even do it at the session level. The issue is that *all* sessions must know for a fact that no other session can write to the tables in order to turn off the locking and change detection and improve performance. The only way to do so is via the table metadata or via the OS.>> But why can You leave that to a programmer. If I set session to be read-only, just assume that no other session will write to the tables and turn off locking and change detection. Let it be a special case and worn programmers that it is to them to prevent writing to those tables. Or, here is another idea. Why not put read-only/read-write flag in dbisam.lck file. On every open check this flag. If it is set to read-only threat it as read-only attribute. (FMarkedReadOnly) |
Mon, Jul 16 2007 6:35 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Igor
Why not add a bit of code to your app to toggle the read only attribute of the three files making up a table? Roy Lambert |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Saturday, April 27, 2024 at 08:52 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |