New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Jonathan Allen on Sep 30, 2006
Microsoft has a tough decision. They can either concentrate on the next version of Visual Studio, with features such as LINQ, or they can ensure Visual Studio 2002/2003 works Vista.
Comments such as these are common on the Microsoft web logs:
Seeing that the support for VS2003 will not be present on Vista is a bit worried for us. We've lots of large customers that works with .NET 1.1 applications and surely they will not be ready for a migration soon. In second, we work a lot on the Dynamics platform, and here .NET 1.1 is he standard.
Should we plan to have a machine with Vista and a machine with XP? Not so good... By doing this, you'll see that XP will be the main platform for a lot of time.
Stefano Demiliani
Visual Studio .NET 2003 is a product that was out 2+ years ago. Many of our customers, partners and vendors still rely on it. Not supporting VS 2003 and/or .NET 1.1 is harshly forcing everyone to upgrade to 2005 version. Many IT Departments and CTOs are unable to justify the upgrade in such a short span of time.
Wilson Loo
While there isn't a lot of vocal support for their decision, Microsoft is standing firm for both technical and financial reasons.
Development tools as a whole have requirements that are not a part of normal applications. Some of the things developer tools expect to do are also the types of things that malicious code tries to perform on a user machine. As you all know, the Windows team has continued to make great progress w/Vista on the security front. There are a number of new security related work and features that are a part of Windows Vista. In the case of Visual Studio, things like debugging while attaching to a process requires reading and modifying that process’ memory, or registering a COM component directly conflict with the principles behind some of the new security features in Windows Vista.
I’ve also clearly heard the concern around our decision not to support VS.NET 2003. We know from talking to customers that some of them have been successful in using VS.NET 2003 and VS2005 on Windows Vista when running as an administrator on the machine. However, there are some scenarios, like those I described above, that will not work. Going forward, we will provide more details on what these issues are and any known workarounds that you can use. Also, when we have fixes to workaround some of these problems, we will make them available.
Like you, we have resource constraints. It might look like Microsoft is a huge company with infinite resources but, unfortunately, it’s not. We are just as constrained as everyone else in the world as to how we invest our time and money. I can assure you we have spent a lot management time wringing our hands over what the right thing to do here is. All work we do comes at an opportunity cost. For example, if we go back and make VS2002 work on Vista, we have to trade that off against not making progress on Orcas. Ultimately, we balanced all of these trade-offs and came up with this plan. The plan is to support our run time environments on Vista and to support VB6, VS2005, Orcas and all future versions. Would it be good to support more? Yes. Is it worth the opportunity cost? We think it isn’t.
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
A Guide to Branching and Merging Patterns
SCM best practices for multiple processes, releases & distributed teams
.. is that .NET 1.1 support is missing from the newer tools. There are three issues here. First, and most importantly, will .NET 1.1 applications work on Vista? Second, will .NET 1.1 applications be buildable and maintainable on Vista? Third, will the old VS2003 work on Vista? Arguably, all three are obvious and important, and right now the second and the third are coupled.
Peace,
Cameron Purdy
www.tangosol.com/
Microsoft has the resources to branch VS2003 and continue to support it with a dedicated team of developers for the next hundred years, and at the same time develop a completely new/different VS for Vista, if they want to. Its a matter of priorities and willingness to support the current customer base.
In my opinion, what they really want is to move everyone to Vista as soon as possible, and forcing the developers to move first is a key strategy in making that happen.
My question is:
Will (and should) VS2005 be supporting .NET 1.1 projects (on XP or Vista)?
I don't understand how not ensuring VS2003 works on Vista will force developers to use Vista. I think the opposite is true -- it could be a barrier to adoption for Vista. If you need to use VS2003, then you also stay on XP. The comment by Brian Harry says that the runtime environments (which I take to include .NET 1.1) will work on Vista, just not the development environment.
Agree with Eric.
How about using Virtual PC for the VS 2003 development? If added enough RAM on the developers' workstations, they could use the virtual machine to work on VS 2003. The developers do not need to worry about if they need to upgrade to Vista or not.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
5 comments
Watch Thread Reply