Will Delphi and EWB applications accessing DBISAM tables at the same time, recognize each other's locks when transaction processing is enabled during saves and deletions in multiple tables?

Frederick

Why would you think it doesn't do that now?

Don't forget EWB Server (accessing the database) is stateless.  

The backend server - just serves up the data - it does not lock things and waiting for another request.  Each request is independant.

Walter

Transaction processing in EWB - IS NOT DATABASE transaction processing.  The construct in EWB of a Transaction - is the ewb app, within the browser preparing an automatically JSON request to go back to the server to do the database work.  TRANSACTIONS in EWB are the preparation of database requests.  (See EWB Help)

See my other post - think of the server as a web API service.  It just services request.

You have to think/plan differently your web applications.  It is like multi-tier - the browser is the UI (with some extra smarts ie javascript routines) and the server is the middle tier and does the database work and any other work you may need - like emailing....  while it also serves up the images and html, php, js and other files to the browser.

Walter

Walter Matte wrote:

/*
The backend server - just serves up the data - it does not lock things and waiting for another request.  Each request is independant.
*/

If the backend server (I presume to be the EWB web server) just serves data, which part of the process informs the Windows application that the table cannot be temporarily locked to store data.

The DBISAM database server is not used in this scenario.

Frederick

Frederick:

//**
If the backend server (I presume to be the EWB web server) just serves data, which part of the process informs the Windows application that the table cannot be temporarily locked to store data.

The DBISAM database server is not used in this scenario.
**//



In a desktop windows program that opens a database to do work - keeps the connection to the database for the whole time the program is running.


In a web browser application you have no database.  You can only send a request over to the EWB web server to do some database work for you.   When the EWB web server gets a request - it opens the database - does the work, closes the database and sends back the response.  There is no permanent connection between the browser and the database as there is in a windows program.

Example - in the windows program you open a table - it is open until you close it.

In EWB you load a dataset with data - the server gets the request - opens the table - sends the data - closes the table.  Now here is the important thing.  When the server request is finished and data sent back in the response - the server no longer has any connection or knowledge of the browser app.  

If you study the EWB Transaction process you see that the JSON being set to the ewb server has BEFORE and AFTER values and must include primary or unique key information.  So that the server can find and update the data.  The ewb server needs to generate an UPDATE statement from the JSON provided.

That is why I said that designing web apps is different than desktop programs.

The browser and the database are not connect.  So you cannot "Lock" records from the browser.

Walter

Walter,

/*
In a web browser application you have no database.  You can only send a request over to the EWB web server to do some database work for you.   When the EWB web server gets a request - it opens the database - does the work, closes the database and sends back the response.  There is no permanent connection between the browser and the database as there is in a windows program.
*/

Thanks for the detailed explanations.

I guess I have to write a test Windows application that performs a lengthy transaction and see what happens to the EWB application when it tries to update a table in the transaction and vice versa. (I am still waiting for the release of the latest EWB)

It seems to good to be true that a Windows program and an EWB application can work seamlessly together but I have to be 100% sure that this will happen without data corruption.

Frederick

On 12/30/2016 10:15 AM, Frederick Chin wrote:
> I guess I have to write a test Windows application that performs a lengthy transaction and see what happens to the EWB application when it tries to update a table in the transaction and vice versa. (I am still waiting for the release of the latest EWB)

> It seems to good to be true that a Windows program and an EWB application can work seamlessly together but I have to be 100% sure that this will happen without data corruption.

Frederick,

There is no data corruption issues - EDB trnasactions and locking take
care of that.

However locking can still have an impact in your case : if delphi app
starts a transaction and then leaves it open for a long time could
impact EWB server (Lock it out) for any inserts/updates/deletes.

EWB web server will also technically lock tables since every
insert/update/delete operation uses an implicit restricted transaction
in EDB but that is very quick so unlikely you'll notice that in your
delphi app.

So always try to keep all transactions short and consider optimistic
locking (if that works for delphi app).

I assume EWB web server uses the default transaction Timeout (-1) and
that should be couple of minutes before it times trying to obtain a
transaction lock.

Raul

On 12/30/2016 11:05 AM, Raul wrote:


> I assume EWB web server uses the default transaction Timeout (-1) and
> that should be couple of minutes before it times trying to obtain a
> transaction lock.

Ignore this part - this assumes EDB database

For DBISAM the engine level settings (TableTransLockRetryCount and
TableTransLockWaitTime) control the wait time when trying to start a
transaction.

EWB web server does not surface these AFAIK so it uses DBISAM defaults
which should be well over a minute or few of trying to obtain a lock (I
recall it being some 96 seconds as it's based on retry count and
interval but don't quote me on that).

Raul

Raul,

Thanks for the detailed information.

I'll keep them in mind when I create both applications.

Frederick