Wednesday, September 29, 2004

Frameworks Encourage Poor Threading Models A thread on The Server Side (http://www.theserverside.com/news/thread.tss?thread_id=29012) turned to talking about a topic of special interest to me, namely application architectures for high performance high load situations. Here are some thoughts on the subject of architecture: http://www.possibility.com/epowiki/Wiki.jsp?page=AppBackplane. They are the result of years of conversations with some very smart people working in one of the most difficult environments possible, a Class 5 core telecom switch. Comming to the java application server world of servlets, hibernate, struts, spring, etc, i was confused at first by how these frameworks dictated the threading architecture of applications by using ThreadLocal and a single threaded approach for all requests. I am curious if people are inerested in other approaches to application architectures? Anyway... > From the thread: >don't you break with the common one thread per request > scenario that us developers have come to depend on? It needs to be broken. These frameworks force an application architecture. Your application architecture shouldn't be determined by a servlet or a database or anything but the needs of your application. Sure, a single threaded approach may work fine for a stateless web back end. But what if you are doing a real application on the backend like handling air traffic control or a manufacturing process? In these cases a single threaded approach makes no sense because a web page is just one of a thousand different events an application will be handling. All events are not created equal. Threads, queues, priorities, CPU limits, batching, etc are all tools you can use to handle it all. It took me a while to figure out why i was having problems with certain frameworks. It is because they hard code a threading architecture into your apps. If i want an object to participate in transactions from multiple threads, hibernate would barf saying an object can't be in more than one session. Or an AOP approach would just assume it knew my transaction scope. That perplexed me until i saw that everything works that way. It makes some sense as the default mode for simple web apps. If i have work to do that i want handle smartly, you can't use the common frameworks. Why different threads? Read the SEDA papers for a good introduction. It has a lot to do with viewing your application performance as a whole, instead of a vertical slice in time. With a multi threaded approach you can create the idea of quality of service. You can have certain work done at higher priorities. You can aggregate work together even though it came in at different times. You can green light high priority traffic. You can reschedule lower priority traffic. You can drop duplicate work. You can limit the CPU usage for work items so you don't starve other work. You can do lots of things, none of which you can do with a single task that runs until completion. comment[] 11:06:22 AM

© Copyright 2006 todd hoff. Last update: 7/11/2006; 1:05:39 PM.