Am Dienstag, den 18.04.2006, 14:27 -0700 schrieb johnf:
> Yes, it is true if my user opens 10 forms I will have ten
> connections and if I have 100 users I will have 1000 connections open. This
> of course sounded like a lot. But then I realized that today Postgres can
> handle thousands of connections without issue. In fact 1000 connections uses
> only 50K of extra ram. With todays fast CPU's controlling 1000 connections
> is nothing. But what about the time to open each connection? On a LAN I
> doubt it amounts to much. On my LAN we are talking about micro-seconds per
> connection (at least that is what is reported in the log). But on a dial-up
> - Maybe! So in the end I guess it really doesn't matter.
Thanks to your report I see no problems in the number of connections at
all but I fear design trouble in writing the persistance layer in a way
independant from the database without having too much code dealing with
a special kind of database - but that was only a dream, I think. ;)
> BTW in my app I
> doubt if my users will have ten forms open at the same time. Also in my app
> I close the connection each time I close a form. One nice thing as result of
> using a connection per form - I no longer attempt to control the locking in
> anyway. I let Postgres use it's record locking schema. I just use a try to
> catch the error if there is a locking issue. So far I can not create any
> locking issues even in code. Postgres is faster than I can update the data.
I'll have to deal with multiple transactions, sort of bulk updates
together with XML-RDB-mapping, this will be important when coupling to
the client app(s) has to be done. But all of this is in it's early
planning stages, I haven't evaluated native XML databases yet.
> Hope this helps!
It does, thank you.
Regards,
Marc
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
