http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I would write that the more critical issue is the synchronous invocation of GetShoppingCart during which a thread-pool thread is locked for the entire round-trip through the tiers. Under load, your scalability will be limited to "throwing hardware" at the problem. Rewrite GetShopping cart as an asynchronous call with a timeout callback. Also, I have a subjective dislike for "var"; it has a use in LINQ, yet when the datatype is known, I enforce the use of "int" or "string" over var(iant). Then again, I also firmly believe programming SHOULD be hard. Nick http://ayende.com/3429/unstable-code#comment52http://ayende.com/3429/unstable-code#comment52Wed, 06 Aug 2008 12:00:55 GMTWhat do you do in the case of new customers? I am assuming that a new customer would get an id assigned to them the minute they put something into the shopping cart, even if they are not a pre-existing customer, which invalidates my question. :D http://ayende.com/3429/unstable-code#comment51http://ayende.com/3429/unstable-code#comment51Tue, 22 Jul 2008 20:31:13 GMTSee future posts to show how you will NOT get time out exceptions http://ayende.com/3429/unstable-code#comment50http://ayende.com/3429/unstable-code#comment50Tue, 22 Jul 2008 10:40:47 GMTOren, can't understand why you call this code unstable. You will get TimeoutException on timeout showing that data just could not be retrieved. This is an adequate and real-world error, isn't it? Do you know other ways dealing with this? http://ayende.com/3429/unstable-code#comment49http://ayende.com/3429/unstable-code#comment49Tue, 22 Jul 2008 10:09:42 GMTOrEn, I apologize for this mistake for Your name:/ I'm sorry. http://ayende.com/3429/unstable-code#comment48http://ayende.com/3429/unstable-code#comment48Tue, 22 Jul 2008 06:15:20 GMTAlan, In the scenario where the cart is considered a resource as well, what exactly is wrong with using the customer id to identify the cart itself? Specially given that every customer can have at most one cart. I am just trying to think what makes storing a cart id more RESTful than storing a customer id since at the end of the day, the client side will have to send a number to the server ('customerSvr/carts/customerId' or the like). http://ayende.com/3429/unstable-code#comment47http://ayende.com/3429/unstable-code#comment47Tue, 22 Jul 2008 00:46:50 GMTOren and I have had an off-post dialogue about this. In short, I believe that he disagrees with my premise on the basis that he feels that my assumptions are wrong (not wishing to put words into his mouth). Anyway, I thought it would be useful to post some of the links that I passed to Oren during the discussion so readers can make up their own minds. It may make more sense when you consider that server cookies are not permitted in REST. Also note that Roy addresses the question of application state in [1] below. If you promote the cart up to being a full resource, then we are talking a different game. For a start, we are no longer looking at a traditional ecommerce platform cart implementation (if the promotion is RESTful, that is). For one thing, the cart state would have no relationship with an individual (that is to say, all people with the same cart contents would reference the same cart resource). Given that your example specifies a customerId, it doesn't seem to fit the RESTful model (it would if it took cartId instead). "REST goes further and constrains application state (not resource state) to be held on the client. […] we can think of it as the context between user agent requests: the server cannot be aware of any such context and still be REST." Roy Fielding [1] "Authentication is orthogonal. Cookies are also orthogonal when they are simply used for content negotiation or authentication. However, Cookie authentication is not allowed in REST because it lacks visibility, which causes security problems […]" Roy Fielding [2] "Stateless in REST refers to the ability of the server to not know about prior requests in order to completely understand the current request." Roy Fielding [3] "Application state in REST is what most distributed systems would call session state or transaction state, depending on which end of the system is being talked about. " Roy Fielding [4] [1] http://tech.groups.yahoo.com/group/rest-discuss/message/3583 [2] http://tech.groups.yahoo.com/group/rest-discuss/message/3729 [3] http://tech.groups.yahoo.com/group/rest-discuss/message/4165 [4] http://tech.groups.yahoo.com/group/rest-discuss/message/10256 http://ayende.com/3429/unstable-code#comment46http://ayende.com/3429/unstable-code#comment46Mon, 21 Jul 2008 20:15:43 GMTYou can probably set the timeout using the configuration, but it doesn't really help http://ayende.com/3429/unstable-code#comment45http://ayende.com/3429/unstable-code#comment45Mon, 21 Jul 2008 19:00:59 GMTAlan, How does the server know of the client state? http://ayende.com/3429/unstable-code#comment44http://ayende.com/3429/unstable-code#comment44Mon, 21 Jul 2008 16:32:50 GMT"What is wrong with this code?" The server knows the client state. This is contrary to the Stateless REST constraint [1] The solution: move the cart state to the client. [1] http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_1_3 http://ayende.com/3429/unstable-code#comment43http://ayende.com/3429/unstable-code#comment43Mon, 21 Jul 2008 16:16:26 GMTReally!? Ouch - how could that be, especially in a stateless web application, can you explain? I've never experienced other threads being blocked whilst making a sync service call. Even an Async call is essentially a sync call but done in another thread or using an iocompletion port. Or are you saying we should be making duplex service calls to avoid possible problems? I'm currently working on developing an inherited financial application and there are loads of sync calls to WCF services. So far we've had no problems but don't want them to bite us in the future! :-S http://ayende.com/3429/unstable-code#comment42http://ayende.com/3429/unstable-code#comment42Mon, 21 Jul 2008 16:07:39 GMTNeil, It means that a sync blocking remote call is dangerous. It is very likely to block all your threads in such situations http://ayende.com/3429/unstable-code#comment41http://ayende.com/3429/unstable-code#comment41Mon, 21 Jul 2008 15:37:23 GMTAditya, You have just described the way Sagas works in NServiceBus :-) http://ayende.com/3429/unstable-code#comment40http://ayende.com/3429/unstable-code#comment40Mon, 21 Jul 2008 15:36:11 GMTHmm... surely whether to make Async calls to the service layer or not is a scalability issue rather than a stability issue? Here you are blocking worker threads meaning your app can't scale and process more requests? http://ayende.com/3429/unstable-code#comment39http://ayende.com/3429/unstable-code#comment39Mon, 21 Jul 2008 14:00:43 GMTSo, what's the recommended way to fix the possibility of blocking? Something I thought of is the following: Since we seem to be using a message oriented transport mechanism, we can treat each call as state in a state machine. After having made the call, we can put aside this state machine and process more messages. When we receive a message with the cart from the AppServer or the DB we proceed with whatever we were going to do to the cart. Periodically, we check to see how long any state machine is in a 'wait' state and then mark the required ones as timed out...and display a error message to the user or the like. http://ayende.com/3429/unstable-code#comment38http://ayende.com/3429/unstable-code#comment38Mon, 21 Jul 2008 13:58:10 GMTYou wrote "no configuration mistakes". I'm not into WCF and if it's such a lousy crap that I cannot configure global timeouts, it's not worth looking at it... http://ayende.com/3429/unstable-code#comment37http://ayende.com/3429/unstable-code#comment37Mon, 21 Jul 2008 13:53:54 GMTmeowth. My name is Oren. It all goes back to the laws of leaky abstractions. This is not something that you can easily hide, nor do you want to. This should be directly exposed in the UI http://ayende.com/3429/unstable-code#comment36http://ayende.com/3429/unstable-code#comment36Mon, 21 Jul 2008 13:48:39 GMTJuliano, God, No. That never even occurred to me. Note that your approach is just a derivation of the problem of failing contracts. http://ayende.com/3429/unstable-code#comment35http://ayende.com/3429/unstable-code#comment35Mon, 21 Jul 2008 13:47:49 GMTOrin, thank you a lot for this question, it was really useful and interesting to ortogonate my view =) But, I still thinking, that the problem of blocking of such type should be solved by another application logic layer (by building and configuring communication facilitites - thru AOP weaving and so on), and not directly by hi-level API - so configuration is not so perfect ;) Any way, thank you once again. http://ayende.com/3429/unstable-code#comment34http://ayende.com/3429/unstable-code#comment34Mon, 21 Jul 2008 13:45:32 GMTGetShoppingCart is a method pointed to a database Stored Procedure or function, so the Database programmer can change it without assent, and the "contract" become invalid. Am I wrong? http://ayende.com/3429/unstable-code#comment33http://ayende.com/3429/unstable-code#comment33Mon, 21 Jul 2008 13:44:12 GMTmeowth, The reason that I am posting those is to show the issue and have the discussion. I could just post my solution, but it is more interesting to have a discussion. This is always unstable code, regardless of the circumstances. http://ayende.com/3429/unstable-code#comment32http://ayende.com/3429/unstable-code#comment32Mon, 21 Jul 2008 13:38:41 GMTAhh i see... well now I have no idea and I am getting increasingly worried about the application I am working on which has a similar architecture! So I'm looking forward to finding out the answer... will of course post again I think of anything! :) http://ayende.com/3429/unstable-code#comment31http://ayende.com/3429/unstable-code#comment31Mon, 21 Jul 2008 13:37:18 GMTThank you, Orin, picture started to look much better =) So the question was - not 'invalid code', but 'unstable'? So, you are stating that this code can become 'bad' due to special circumstances. It is left to search out those circumstances you are mentioning =) For the first time I see that if you started to play with transaction level from serializable to at least "dirty read" on db server, you can have dirty data in DTO. Let's start to explore further =-) Hope don't annoy you so much http://ayende.com/3429/unstable-code#comment30http://ayende.com/3429/unstable-code#comment30Mon, 21 Jul 2008 13:37:09 GMTAditya, Ding! Ding! Ding! You got it. I was beginning to get worried. We have a blocking remote call here, and that is almost always a stability nightmare. http://ayende.com/3429/unstable-code#comment29http://ayende.com/3429/unstable-code#comment29Mon, 21 Jul 2008 13:37:02 GMTTommaso, I don't want to do that. That makes my life harder than it should. For that matter, don't assume we are talking WCF here. http://ayende.com/3429/unstable-code#comment28http://ayende.com/3429/unstable-code#comment28Mon, 21 Jul 2008 13:35:15 GMTHow are timeouts being handled? Or rather, what happens if the call never returns? http://ayende.com/3429/unstable-code#comment27http://ayende.com/3429/unstable-code#comment27Mon, 21 Jul 2008 13:34:55 GMTWCF is a connected technology, so you can insert a sort of Service Dispatcher in your architecture in order to have for each client a "private" set of services without passing every time the customerId. http://ayende.com/3429/unstable-code#comment26http://ayende.com/3429/unstable-code#comment26Mon, 21 Jul 2008 13:33:39 GMTDoesn't matter for the problem at hand. Assume all book keeping is done correctly. Don't assume that it is WCF, by the way. It was an example to make sure that you will get the idea. http://ayende.com/3429/unstable-code#comment25http://ayende.com/3429/unstable-code#comment25Mon, 21 Jul 2008 13:31:46 GMTIn WCF, you need to wrap that call in try-finally block and call customerSrv.Close() in the finally. Also call customerSrv.Abort() if the customerSrv.Close() throws an exception. http://ayende.com/3429/unstable-code#comment24http://ayende.com/3429/unstable-code#comment24Mon, 21 Jul 2008 13:28:32 GMTCalls to GetShoppingCart can return different versions of the same cart, yes. And updating the cart may require reconciliation. Still not the issue http://ayende.com/3429/unstable-code#comment23http://ayende.com/3429/unstable-code#comment23Mon, 21 Jul 2008 13:24:56 GMT