Data Access Components, TDatabase, TSession with Distributed application

Thread View: borland.public.cppbuilder.database.multi-tier

5 messages

[T] Back to Threads [V] Tree View [G] Group Articles

5 total messages Started by woody steven Tue, 17 Apr 2001 01:29

#670

Author: woody steven
Date: Tue, 17 Apr 2001 01:29

27 lines
1914 bytes

Hi,

Borland's database application based on the structure:
Application -> Data Access Components -> Session -> TDatabase.
The key in here is simple and clear, every data access component has a
'databasename' property, with this, a global (or user defined) TSession
object can find the relative TDatabase object for the requester.  So I
belive, the TSession object play as a bridge between data accessors and
the database connnection.

I am now interesting what would happen when the world changed from c/s
to distributed. For example, if the data access components and the
TDatabase reside in different modules (i.e. corba client and server),
can the data accessors still comunicate with the relative TDatabase?
Where the TSession object get play?

Yes, I know, Borland support MIDAS, but in the architecture, only the
data-awares get apart, and this architecture is not flexible relative to
some common solutions like corba and dcom.

Any opinion and answer would be appraticated.


Regars,

steven
woodysteven@163.com

Re: Data Access Components, TDatabase, TSession with Distributed application

#675

Author: Mark Cashman
Date: Wed, 18 Apr 2001 03:22

25 lines
2003 bytes

Hi, Woody!

If you want to use CORBA and not MIDAS with a CORBA connection, then you
need to create and manage your own data transfer protocol - for instance
passing records as CORBA data structures on demand. In theory, you could
create a TCustomDataSet descendant that would abstract this away so that
each CORBA object couild pretend it was dealing with a local data set,
but in practice, use of MIDAS would be a lot less expensive that
producing that component.

The Session / Database / Dataset, except for the illusion provided by
MIDAS, is purely local to a specific program (actually to a thread).

I'm sorry to not be more help, but I hope this makes it easier to see
what you may need to do.


------
Mark Cashman (TeamB - C++ Builder), creator of The Temporal Doorway at
http://www.temporaldoorway.com
- Original digital art, writing, music and more -
C++ Builder / JBuilder Tips and The C++ Builder Programmer's Webring
(Join us!)
http://www.temporaldoorway.com/programming/index.htm
------

Re: Data Access Components, TDatabase, TSession with Distributed application

#680

Author: Dmitri Bobkov
Date: Fri, 20 Apr 2001 22:16

43 lines
2732 bytes

Hi Mark,

Could you tell us who is the Guru in all this MIDAS staff
and can explain how to work with such enterprise from
255 simultaneous users? Is it enterprise solution?
Might be we are doing something wrong? (see my msg. from Apr 19th in this
group)
How to manage BDE to open more sessions using all available limits
( 48 clients x 256 sessions = 12288 per system, assuming and controlling
that the only one AppServer will work with BDE on Server machine ?)

Any help will be greatly appreciated
Dmitri

"Mark Cashman" <mcashman@temporaldoorway.com> wrote in message
news:3ADD0865.96AFE583@temporaldoorway.com...
> Hi, Woody!
>
> If you want to use CORBA and not MIDAS with a CORBA connection, then you
> need to create and manage your own data transfer protocol - for instance
> passing records as CORBA data structures on demand. In theory, you could
> create a TCustomDataSet descendant that would abstract this away so that
> each CORBA object couild pretend it was dealing with a local data set,
> but in practice, use of MIDAS would be a lot less expensive that
> producing that component.
>
> The Session / Database / Dataset, except for the illusion provided by
> MIDAS, is purely local to a specific program (actually to a thread).
>
> I'm sorry to not be more help, but I hope this makes it easier to see
> what you may need to do.
>
>
> ------
> Mark Cashman (TeamB - C++ Builder), creator of The Temporal Doorway at
> http://www.temporaldoorway.com
> - Original digital art, writing, music and more -
> C++ Builder / JBuilder Tips and The C++ Builder Programmer's Webring
> (Join us!)
> http://www.temporaldoorway.com/programming/index.htm
> ------
>
>

Re: Data Access Components, TDatabase, TSession with Distributed application

#681

Author: Mark Cashman
Date: Sat, 21 Apr 2001 02:11

13 lines
1580 bytes

I find it hard to imagine the computer on which you are running is large
enough to sustain that level of concurrency, even under NT.

Why do you need 256 threads per client?

------
Mark Cashman (TeamB - C++ Builder), creator of The Temporal Doorway at
http://www.temporaldoorway.com
- Original digital art, writing, music and more -
C++ Builder / JBuilder Tips and The C++ Builder Programmer's Webring
(Join us!)
http://www.temporaldoorway.com/programming/index.htm
------

Re: Data Access Components, TDatabase, TSession with Distributed application

#684

Author: Dmitri Bobkov
Date: Mon, 23 Apr 2001 14:13

44 lines
2620 bytes

Hi Mark,

May be I described our situation unclear.

We are using DCOM in Apartment threading model running as Remote AppServer,
from client side we have just normal application connected to AppServer
through
TDCOMConnection and uses TClientDataSets. Our sever has one RDM which
contains one shared DB object,
one TSession object with AutoSessionName, many TQueries, TUpdateObjects and
TDataSetProviders,
multithreading.

As we figured out, AppServer allows to have only 256 clients connected
because BDE treated AppServer in DCOM implementation like one client app
 on that machine ),
and all the threads created inside AppServer ignored by BDE as new client
connections
and BDE allows to have in this case only 256 sessions open for whole
AppServer.
But we actually must to support more simultaneous connections.

What's wrong in our schema?

Dmitri


"Mark Cashman" <mcashman@temporaldoorway.com> wrote in message
news:3AE0EC41.F72DDAE9@temporaldoorway.com...
> I find it hard to imagine the computer on which you are running is large
> enough to sustain that level of concurrency, even under NT.
>
> Why do you need 256 threads per client?
>
> ------
> Mark Cashman (TeamB - C++ Builder), creator of The Temporal Doorway at
> http://www.temporaldoorway.com
> - Original digital art, writing, music and more -
> C++ Builder / JBuilder Tips and The C++ Builder Programmer's Webring
> (Join us!)
> http://www.temporaldoorway.com/programming/index.htm
> ------
>
>

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads