Subject | Re: [firebird-support] Transactions in MDI application |
---|---|
Author | unordained |
Post date | 2004-09-29T23:18:36Z |
Okay, this might take some explaining.
Under most circumstances, you don't need your lists/grids to contain data from only a 'certain
point in time' -- it's possible, but it's not common. Because of this, your lists/grids can either
be setup to close/start a new transaction each time they refresh, or to just reselect data while
in 'read-committed mode' (on the transaction.)
The transaction determines "what you can see", among other things. Datasets rely on transactions to
give them access to data, so transactions must be open first, before the dataset. The dataset
should close before the transaction. Transactions do not generally automatically re-open after
closing. You have to ask for them to start. (They do, with some components, automatically start
when the transaction object is first created. As there's not much else you'd want to do with a
transaction object other than start it, that makes sense.)
You'll need some mechanism to make lists/grids update with new/modified information. When this
notification occurs, you will either close the dataset and transaction, start a new transaction,
dataset, and reselect, OR you will continue to use a 'read-committed' transaction which will allow
the dataset to see the new information when it reselects the data. We personally don't like read-
committed, and actually start new transactions each time. (I know that'll make some people cringe.)
As to how to make this happen, solutions vary. We created our own tcp/ip message server, and all
our code that creates/modifies rows sends out messages to a central server that then sends those
messages to all connected clients. Those clients look at the message to see if it's relevant, and
if so, the affected (or possibly affected) lists/grids refresh as described above. We try to make
sure we don't refresh more listviews than we need to -- a listview will be set to refresh only if
it sees a message like "referrals.person_id=25", when viewing referrals for person 25. It still
refreshes more than necessary, but not by much.
Firebird has an 'events' mechanism that we do not use, but you could probably ask others for
helping using that instead. (I don't know how other people go about this sort of 'notification'
between database clients, but events only support rather short strings. Maybe they could indicate
you have new messages in a temp table in a database, which you could then look at? I don't know.)
Just never, ever try to use Win32 Samba "mailslots" for notification. It's serverless (sort of) but
so slow, you'll cry.
As to "modules" -- create your MDI child forms like you would expect to, as separate modules. Just
make sure they all know how to send/receive notifications of changes, and act accordingly. In fact,
it would help to make sure you think about them separately -- even if two MDI forms are together
in -your- instance of the application, another user on another computer is entirely separate. If
you think of them as separate, it doesn't matter if the list/grid you need to refresh is in the
same application that made changes, or in another application on the same machine, or in an
application on a computer on the other side of the network.
Let us know how we can help,
-Philip
---------- Original Message -----------
From: "Planles" <planles@...>
To: "Firebird" <firebird-support@yahoogroups.com>
Sent: Wed, 29 Sep 2004 15:12:57 +0200
Subject: [firebird-support] Transactions in MDI application
Under most circumstances, you don't need your lists/grids to contain data from only a 'certain
point in time' -- it's possible, but it's not common. Because of this, your lists/grids can either
be setup to close/start a new transaction each time they refresh, or to just reselect data while
in 'read-committed mode' (on the transaction.)
The transaction determines "what you can see", among other things. Datasets rely on transactions to
give them access to data, so transactions must be open first, before the dataset. The dataset
should close before the transaction. Transactions do not generally automatically re-open after
closing. You have to ask for them to start. (They do, with some components, automatically start
when the transaction object is first created. As there's not much else you'd want to do with a
transaction object other than start it, that makes sense.)
You'll need some mechanism to make lists/grids update with new/modified information. When this
notification occurs, you will either close the dataset and transaction, start a new transaction,
dataset, and reselect, OR you will continue to use a 'read-committed' transaction which will allow
the dataset to see the new information when it reselects the data. We personally don't like read-
committed, and actually start new transactions each time. (I know that'll make some people cringe.)
As to how to make this happen, solutions vary. We created our own tcp/ip message server, and all
our code that creates/modifies rows sends out messages to a central server that then sends those
messages to all connected clients. Those clients look at the message to see if it's relevant, and
if so, the affected (or possibly affected) lists/grids refresh as described above. We try to make
sure we don't refresh more listviews than we need to -- a listview will be set to refresh only if
it sees a message like "referrals.person_id=25", when viewing referrals for person 25. It still
refreshes more than necessary, but not by much.
Firebird has an 'events' mechanism that we do not use, but you could probably ask others for
helping using that instead. (I don't know how other people go about this sort of 'notification'
between database clients, but events only support rather short strings. Maybe they could indicate
you have new messages in a temp table in a database, which you could then look at? I don't know.)
Just never, ever try to use Win32 Samba "mailslots" for notification. It's serverless (sort of) but
so slow, you'll cry.
As to "modules" -- create your MDI child forms like you would expect to, as separate modules. Just
make sure they all know how to send/receive notifications of changes, and act accordingly. In fact,
it would help to make sure you think about them separately -- even if two MDI forms are together
in -your- instance of the application, another user on another computer is entirely separate. If
you think of them as separate, it doesn't matter if the list/grid you need to refresh is in the
same application that made changes, or in another application on the same machine, or in an
application on a computer on the other side of the network.
Let us know how we can help,
-Philip
---------- Original Message -----------
From: "Planles" <planles@...>
To: "Firebird" <firebird-support@yahoogroups.com>
Sent: Wed, 29 Sep 2004 15:12:57 +0200
Subject: [firebird-support] Transactions in MDI application
> Hello!------- End of Original Message -------
>
> I have still some problems understanding, how transaction should be used.
>
> I have a MDI application, intended to work with multiply users, using BCB6
> and its IBX components, FB 1.5.
>
> Small example:
> one MDI child form is for Clients data, second MDI child form is for Orders.
>
> Basicaly, what I expect, is, if both MDI childs are opened, if I add new
> Client in client's table, I should "see" this client in Orders form, if I
> make a lookup on Clients table. I expect also, if another user enters new
> client, that this one should be visible for me the same moment.
>
> So, my questions are:
> - should each MDI child had own Transation component ?
> - should all datasets from all MDI childs be in one DataModule, or should
> they be in each MDI child (for purpose of that child) ?
> - when to commit/start transations ?
> - do I have to start transaction each time after commit, or is transaction
> started automatically after Dataset opening ?
>
> Could someone point me to the right direction ?
>
> Regards,
> Primoz
>
> ------------------------ Yahoo! Groups Sponsor --------------------~-->
> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
> Now with Pop-Up Blocker. Get it for free!
> http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/67folB/TM
> --------------------------------------------------------------------~->
>
> Yahoo! Groups Links
>
>
>