Persistent Sessions Threading Model

In order to fully support JDBC clients, as well as customer requests, ASTA 2.5 will contain new features to the PersistentSessions threading model.

When running an ASTA server in PersistentSessions, each remote client will have their own database components (data module) so that the database user name and password can optionally be used. When database work is required in this threading model, each database activity is done in a thread with each client having their own database connection. (This is NOT the most scalable threading model. To scale an ASTA server, Pooled Sessions Threading is encouraged. )

ASTA servers can be started in this mode by putting PersistentSessions on the command line. When running in the Persistent Sessions threading model the following features are now supported:

1. Packet Queries:

With SQLOptions.soPackets set to True and RowsToReturn > 0, an SQL query will execute on the server but only RowsToReturn rows will be returned to the client. With AutoFetchPackets set to True, any visual control that attempts to scroll or access EOF will force the AstaClientDataSet to call GetNextPacket which will launch a new thread on the server using the initial dataset opened on the server by the SQL statement. With AutoFetchPackets set to False you must explicitly call GetNextPacket.

2. Packet Locates

function GetNextPacketLocate(const KeyFields: string;
const KeyValues: Variant; Options: TLocateOptions): Integer;

GetNextPacketLocate works like the TDataSet.Locate but it will use the query created from step #1. Depending on your database on the server, this can be a very fast operation. Using a file server database like DBISAM, locates will use indexes if the SQL does not include a join. The GetNextPacketLocate will call a TDataSet.Locate on the server and return RowsToReturn rows, and place the server side cursor on the position where the locate has positioned it. This can result in very fast fetches on large tables. Your mileage will vary depending on how the database component used on the server handles this.

3. StartTransaction:
Normally in the n-tier model, round trips to the server should be minimized and activities and transactions should be started and ended on the server in one action. Using ApplyUpdates, ASTAClientDataSets send SQL to the server, start a transaction, execute any SQL from the client and then commit or rollback the transaction as necessary. When running Persistent Sessions you can now explicitly start a transaction with the AstaClientSocket.

procedure StartTransaction;

If the server is not running in Persistent Sessions an exception will be raised.

4. procedure EndTransaction(Commit: Boolean):
You can now also end transcactions from the AstaClientSocket.

5. The AstaClientDataSet has the following new methods:

function ParamQueryCount: Integer;

function SendParamterizedQueries: TAstaParamList;

procedure ClearParameterizedQuery;

procedure AddParameterizedQuery(TheSQL: string; P: TAstaParamList);

The following code shows how these can be used. The idea is that any number of parameterized queries can be created and then sent to the server in one call.

procedure TForm1.BitBtn1Click(Sender: TObject);

var

  p: TAstaParamList;

  i: Integer;

begin

  p := TAstaParamList.Create;

  p.FastAdd('LastName', 'Garlandx');

  p.FastAdd('EmpNo', 2);

  with AstaclientDataSet1 do begin

    ClearParameterizedQuery;

    AddParameterizedQuery('UPDATE Employee SET LastName = :LastName ' +

      'WHERE EmpNo = :empNo', p);

    p.ParamByName('Empno').AsInteger := 4;

    AddParameterizedQuery('UPDATE Employee SET LastName = :LastName ' +

      'WHERE EmpNo = :empNo', p);

    p.Clear;

    p.Fastadd('Phone', NewExt.Text);

    p.Fastadd('PhoneExt', OldExt.Text);

    AddParameterizedQuery('UPDATE Employee SET PhoneExt = :Phone ' +

      'WHERE PhoneExt < :PhoneExt', p);

    SendParamterizedQueries;

    p.Free;

  end;

end;