Jump to content
  • Advertisement
Sign in to follow this  
antareus

[.net] Remoting

This topic is 4882 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

At work we're setting up one of those n-tier systems. I'm working on the application server, which issues queries to the database server. The app server constructs a query from the requested criteria, opens up an ODBC connection to the Sybase server, and populates a DataSet using an OdbcDataAdapter. Is this how it is typically done? I'm hoping the DataSet isn't too big to throw across the wire. We're just using a TcpChannel and the two machines are connected via gigabit Ethernet. Does anyone see anything wrong with the approach I described? I've done some work with J2EE, but .NET is a bit of a different beast (I like it better). I'm interested in comments on scalability as well as maintainability. I believe we're aiming for something like 50+ workstations connected to the app server, but a relatively low number (3) of concurrent requests to the database.

Share this post


Link to post
Share on other sites
Advertisement
::Is this how it is typically done?

Not by anyone having read some documentation in the last 10 years.

Odbc is outdated and dead slow. It is not maintained for a longer time now than the .NET framework exists.

* Use at least OleDb, but better,
* if sybase has them, use the sybase natice connection classes.

::Is this how it is typically done? I'm hoping the DataSet isn't too big to
::throw across the wire. We're just using a TcpChannel and the two machines are
::connected via gigabit Ethernet.

.NET 1.0/1.1: the DataSet is always remoted as XML which is big, bloats, slow and stupid. They overlooked it. You CAN transmit it binary, but then YOU have to make the serialization by hand. For .NET 2.0 they finally clean up this mess - having your data take up 10x as much size on the network than needed is just plain stupid. It is more like the WANT to ALSO e XML, and somehow this turned into the default behavior. I would strongly suggest you google around and fix this in your code.

Beides this we never transmit datasets, but leightweight self-written data containers that our generic DAL turns out upon requests fro mthe server.

Lastly: get rid of the TCP channel. The .NET channels suck big time. Visit http://www.genuinechannels.com/ and get some good ones - the genuine channel suite is simply WAY better than anything .NET delivers. For clarification: these are replacement channels, going into the .NET standard infrastructure.

[Edited by - Washu on January 9, 2005 1:06:02 PM]

Share this post


Link to post
Share on other sites
I'll try to be polite(r) (Washu please see to this...)

There are several 'native' .NET data providers for Sybase. You can find one of them here. These will be faster than ODBC.

On scalability: a lot depends on the amount of data and the frequency of retrieving it. You should explore caching posibilities. 3 concurrent requests can even be handled by MS Access. I've buid app's that allow 300 concurrent requests without a thought about it.

On speed AND maintainability: consider using stored procedures.

Please post any and more precise questions and we'll help you out.

Cheers

Share this post


Link to post
Share on other sites
Thanks for the responses. I'm definitely new to this, so I'll take a little bit of 'abuse' if it means I can get good answers.

Quote:
Beides this we never transmit datasets, but leightweight self-written data containers that our generic DAL turns out upon requests fro mthe server.

Exactly my thoughts now - the dataset couples the app server code to the representation inside the database. Nevermind the fact that taking data out from a dataset isn't always pleasant.

On stored procedures: I asked my boss about it during a design meeting but he seemed to reply that they would be too slow for our uses. I don't know either way, so I wasn't going to challenge him on this point in front of others. The '3' concurrent users number comes from the fact that it is a quad-processor machine, with one processor dedicated to doing injection. Not sure how truthful this is, there's a lot in this area I simply don't know (knowing how it works is way different from actual experience). At the moment I'm restricting clients within my Query method through a semaphore, only allowing 3 requests to be processing at any one time. Should the DB server be the one throttling connections?

And I feel like I'm bugging everyone here with these q's; is there a book I can get?

Share this post


Link to post
Share on other sites
Stored procedures are 'always' faster than queries. An ad-hoc query has to be parsed by the server on syntax and a execution plan has to be made. For a stored procedure this has already been done.

Yes, I would let the DBMS handle the number connections. It easy to configure and has less overhead than a custom throttler.

I'd recommend a class/course so you can shoot your questions at a pro.

Cheers

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!