Subject | RE: [firebird-support] Transactions in MDI application |
---|---|
Author | Planles |
Post date | 2004-09-30T09:23:08Z |
Thanks Philip for your extended explanation.
Regards,
Primoz
Regards,
Primoz
> -----Original Message-----
> From: unordained [mailto:unordained_00@...]
> Sent: Thursday, September 30, 2004 1:19 AM
> To: firebird-support@yahoogroups.com
> Subject: Re: [firebird-support] Transactions in MDI application
>
>
> 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
>
> > Hello!
> >
> > 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 Links
> >
> >
> >
> ------- End of Original Message -------
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>