Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 11 total
Thread Problem with blob fields on network
Fri, Jul 6 2007 7:31 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 2Next Page »
Jump to Page:  1 2
Image