Showing posts with label allows. Show all posts
Showing posts with label allows. Show all posts

Thursday, March 22, 2012

A way to control the # of Transport connections

Is there a configuration parameter that allows me to control the number of Transport connections used by service broker? Right now it seems that it just uses one.

There is no such configuration parameter. The only reason to use more than one TCP connection would be if there were multiple NICs having routes to the destination. But since Service Broker does not really bottleneck on the NIC, there was no reaon to add support for multiple TCP connections. However, we may add this support for other reasons.

Rushi

|||

Ok so what should I do if it feels like I am being constrained at around 100 - 150 messages per second through this transport piece? I have done a couple of tests and at one point it seemed if I enqueued more than 100 messages/sec then they would back up into the sys.transmission_queue on the source side. I realize that is by design, but I have been led to believe that I should get something closer to 1,000 messages/sec of throughput between the 2 instances?

Any thoughts?

sql

Monday, March 19, 2012

A temporary database

I have three aspx pages with one form in every page, these three pages allows to register a user. Now when I submit every form on every page the data is sent to the database, but somebody has recommended me to store data in a temporary database file, and when user submit last page (form) store all the data in main database.

I use Sql 2000 Server Personal Edition and VB.NET for aspx pages.
How can I use this temporary database in my aspx page?

Now my first form-page:


<%@.Import Namespace="System.Data" %>
<%@.Import Namespace="System.Data.SqlClient" %
<script language="VB" runat="server">
Dim strConnection As New SqlConnection(ConfigurationSettings.AppSettings("myConn"))

Sub Send_data(sender As Object, e As EventArgs)

Dim CmdInsert As New SqlCommand("new_user1", strConnection)
CmdInsert.CommandType = CommandType.StoredProcedure

Dim InsertForm As New SqlDataAdapter()
InsertForm.InsertCommand = CmdInsert

CmdInsert.Parameters.Add("@.Id", SqlDbType.bigint)
CmdInsert.Parameters("@.Id").Direction = ParameterDirection.Output

CmdInsert.Parameters.Add(New SqlParameter("@.e_mail", SqlDbType.varchar, 50, "e_mail"))
CmdInsert.Parameters("@.e_mail").Value = mail.Text()
……….

strConnection.open()
CmdInsert.ExecuteNonQuery
Dim IdUser As integer = CmdInsert.Parameters("@.Id").Value
strConnection.close()

End Sub

Thanks(1) you can generate an id for each user
(2) insert all the data from each page into some temp database( which you have already created ) using the id
(3) finally call some stored proc tht will move all the info from the temp db to the main one..again using the id...if the user decides to cancel ( at any stage) just empty the temp table.

hth|||Could you recommend me an article, manual, reference,etc.. to start with temporary databases please? I have never worked with them.|||its just another table thts xactly similar in structure to your actual table that you want to put the records in..there are some sys temp tables but i was referring to user created table...sorry if i misled you..

hth|||Before I take the decision of using 'temp tables' I want to know, sure, if it is better passing all the values of the forms with a session variable through the pages until the end, and then do the insert into the main (real) database, or if it is better to do the inserts in every page and use 'temp tables'. Or do the inserts in every page and store the userName and Password in a session variable and do the insert of these 'key' fields in the last page when the registration is complete.

Some experienced ideas please?|||It depends upon the amount of data. Will have have 100 bytes of data over the screens, or 20000 bytes? If 100 bytes, session will be fine, if 20000 then probably not. In addition, rather than using a temp table, you might just want to add a "pending" flag in the real table, and the add data as you go along (with pending set to true) and then on the last page, save last of the data and clear the pending flag.|||I don' t know exactly the amount of data, it is more or less ten fields per page (3 pages). Five with number values and five with text values with max length 50, and some text area field.
Anyway, regardless of the amount of data, Is it better to use a 'pending' flag in the real table? Now I don' t know anything about this system.

Thanks,
Cesar|||I tend to prefer it, as it saves some rewriting of data. Are you already using the Session for other things? If so, it might be reasonable to add this information and then not persist anything in the DB until they are done. With either other plan, you need to have a way to clean up junk (Pending in live or records in the temp).|||Every character is one byte, isn' t it? In afirmative case the amount of data per page will be less than 200 bytes.|||Ok thank you very much|||.NET uses Unicode, so each character in a string is 2 bytes. Either 200 or 400 bytes would be reasonable for the session, unless you have thousands of users, or unless you want to avoid using the session for other reasons.