confussed with reliable messaging and transactions support...

confussed with reliable messaging and transactions support...

• emccormi

  Thanks so much! But i am thinking in something quite new using indigo (i hope i am not writting something too much stupid.).

  As I view the issue my problem is in the inserts, because the updates are timestamped and deletes will mark as deleted, so it would be marked twice with no error. So I keep trying not to store any guid.

  How would you see using distributed transactions for inserts The system is not very crowed, just 60 concurrent connection maximun. I am not an expert with distributed transactions, I know that they require resources and could produce deadlocks, but perhaps it could be an option, inserts does not need deadlocks, does they .

  try

  {

  using(transactionscope... )

  {

  var m=queue.peek

  m.send()

  queue.dequeue() // i would just dequeue it if all was ok, i could implement a transaction queue (it is implemented in the msdn magazine, but i think that is so much.).

  }

  }

  catch

  {

  //error logging and those things...

  }

  How do you see it

  
  
  

• andycsuf

  Reliable messaging is only for transient network interruptions, to make sure that messages are sent in order and acknowledges. The RM queue dies with the session, so this won't work with your scenario.

  MSMQ and transactions would be an obvious choice, if you don't require interoperability.

  Another option is to design a pattern from your smart client to handle this properly:

  • Client writes to local, peristent queue
  • When connected to network (or whenever you want to kick this off) client cycles through queued items to send for processing at the service. Must update the queued item on the client (probably local data store) to indicate it is "in process".
  • Service processes item, interacting with the database, when completed sets a record on the database side that indicates that queued message ID was processed successfully.
  • If you can implement two-way calling, use callbacks to notify the client and update the client queue to remove the item.
  • If you can't use callbacks (most likely) your client needs to have a polling mechanism to see if the message was processed at the service. Probably another service method to check recently processed messages, to update the client queue accordingly.

  
  
  

• Yong Hwee

  uooooooo, i should talk about that queue and bad communications.

  The project consists in clients and one server. Clients are smart-client, so users can work with it although there is no communications.

  The idea is to use a queue for sending messages from the client to the server one by one, if one fails it won't be dequeued, so the queue will retry that message until the server take it. In that way we solve the problem in CRUD order, all will arrive in order. The queue will be saved in disk (using caching app block).

  When I talk about transactions is about putting the sending process in one distributed transaction started by the client, if it fails the server will rollback and the queue won't dequeue the message -look at the client's code now, i should have explained this better-, so we can send the message again and again. What I don't know is why distributed transactions scares people more than The Exorcist. I think this way is 99% reliable, it should fail just if the queue can not queue the object and save it to disk, but this is very improbable and those fails could rollback the transaction too. And i will have just 60 clients, so the server won’t get in performance troubles, isn't it We only need transactions in insert messages, so that reduces the number of transactions.

  Another option could be the use of reliable messaging, it is assured by it that only one message should be delivered, but if the server fails the client won't send the message another time, although the server could return that exception or something to achieve this. But reliable messaging starts and ends with the messaging session, so i could send the message and end the session for any reason, the message will be sent another time and we could have two inserts (inserts are the only CRUD operation not idempotent in my system, so the must be processed by the server only once). The idea could be sending a message in a long session (1 hour), i have tested that the server can go up and down and the message is delivered, but that session can give problems.

  I like the distributed transactions option, i think ws-transactions is really powerful. And a transaction in an insert won't get he table deadlocked, will it I want to be imaginative with wse3.0 and try something new.

  What do you think

  
  
  

• Joey Bradshaw

  There is an awful lot to talk about here, and I have no idea of your business requirements, but if I get you correctly, you are talking about sending CRUD operations in a queued manner, which typically means FIFO (first in, first out) and last in wins execution if the queue is played in order.

  You can use distributed transactions to make sure "the message got into the queue" and is never lost.

  The message playback will be a separate transaction, making sure that the entire message was properly played through the business and data components that it touches.

  But, if one of the CRUD operations fails, how do you handle it Is it ok to update a record after the previous update failed You can't update a record that is deleted in an earlier message. You can't update a record that failed to be inserted. So, you need to log those failures at the server side (since the client will no longer be involved, after having written to the queue safely, it is "done" and considers the message transmitted).

  I'm not sure why you are using a queue, or if you even need one. My comments here assume you need one. You'll need to consider things like:

  • Does the client care about every message, and if it was successfully played Or, will this just be reported through the resulting database state
  • Certainly you should care at the server-side, if a message is not played. So you need exception handling process, and administrative review of the queues to see that there are no dead letter messages.

  The list goes on, because this is a heavy design discussion...

  
  
  
• confussed with reliable messaging and transactions support...