Tim

We are already discussed this issue but I think you should think sooner than "ElevateDB C/S only" product be
released.

If you could put record lock during transactions instead of table lock (restrictive transactions) or database lock in
the ElevateDB, the performance for large database x concurrent users will be much better.

Eduardo

Jose

Check out the thread in elevatesoft,public.discussion from Johnnie Norsworthy titled Locking a Group of Records for Processing (Client/Server)


With EDB, you can
manually lock as many rows as you would like with these methods:

http://www.elevatesoft.com/edb1d5_tedbdataset_lockcurrentrecord.htm
http://www.elevatesoft.com/edb1d5_tedbdataset_unlockcurrentrecord.htm
http://www.elevatesoft.com/edb1d5_tedbdataset_unlockallrecords.htm

Sorry about the lack of docs, they're almost done.


Roy Lambert

Eduardo,

<< We are already discussed this issue but I think you should think sooner
than "ElevateDB C/S only" product be released.

If you could put record lock during transactions instead of table lock
(restrictive transactions) or database lock in the ElevateDB, the
performance for large database x concurrent users will be much better.  >>

It's not as simple as you make it out to be.  Only a client-server only
(single-user) database engine can perform the type of locking and buffer
management necessary to provide the isolation levels so that other users
don't see changes by other users within different transactions.  It's not
just a matter of holding row locks instead of using table-level locks.  The
reason that table-level locks are necessary is to give a consistent level of
isolation between different transactions.

The EDB "client-server only engine" will be a completely different engine in
a lot of respects.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Check out the thread in elevatesoft,public.discussion from Johnnie
Norsworthy titled Locking a Group of Records for Processing (Client/Server)
>>

This is true, but it does not provide isolation.  IOW, a session could read
a value that has been posted by another session, even if the value ends up
being reverted back to its original value with another post by the other
session.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

> It's not as simple as you make it out to be.  Only a client-server only
> (single-user) database engine can perform the type of locking and buffer
> management necessary to provide the isolation levels so that other users
> don't see changes by other users within different transactions.  It's not
> just a matter of holding row locks instead of using table-level locks.
> The reason that table-level locks are necessary is to give a consistent
> level of isolation between different transactions.
My simple approach will be hold SessionID, Database, TableName and RowID in
a main thread visible to ALL sessions connected to the server but if you are
telling me it is not so easy like this...

> The EDB "client-server only engine" will be a completely different engine
> in a lot of respects.
Ok, let us wait for this release too.

Good luck

Eduardo

Eduardo,

<< My simple approach will be hold SessionID, Database, TableName and RowID
in a main thread visible to ALL sessions connected to the server but if you
are telling me it is not so easy like this... >>

Unfortunately it isn't that easy.  Think of a query that uses an index for
optimization.   The index must have information in it to know which
transaction has inserted which index keys and which index keys are visible
to which transaction.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

> Unfortunately it isn't that easy.  Think of a query that uses an index for
> optimization.   The index must have information in it to know which
> transaction has inserted which index keys and which index keys are visible
> to which transaction.

Got it

Eduardo