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.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
The Power of Native Transactions
Presented by
Jürgen Höller
on
Aug 30, 2009
Length 01:15:06
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
Juergen discusses transactions as key to enterprise applications, the different types of transactions, the supposed universality of XA transactions and the alternative of using native transactions using the Spring framework. He talks about native transaction support by modern application frameworks and shares scenarios of Spring Framework users to illustrate the power of native transactions.
Bio
Juergen Hoeller co-founder of Spring Framework, sees 3.0 as the completion of what was started with 2.5. Some topics covered in his presentation are: more annotation-based configuration options, Unified EL++, REST, Portlet 2.0 and Java EE6 support.
About the conference
SpringOne is the annual conference for the global Spring community held in both Europe and the Americas. SpringOne Europe 2009 focused on the emerging technologies and best practices around the Spring Framework and enterprise software development. The event featured the project founders, core committers, authors, consultants, project leads, and professional trainers.
Juergen discusses transactions as key to enterprise applications, the different types of transactions, the supposed universality of XA transactions and the alternative of using native transactions using the Spring framework. He talks about native transaction support by modern application frameworks and shares scenarios of Spring Framework users to illustrate the power of native transactions.
Bio
Juergen Hoeller co-founder of Spring Framework, sees 3.0 as the completion of what was started with 2.5. Some topics covered in his presentation are: more annotation-based configuration options, Unified EL++, REST, Portlet 2.0 and Java EE6 support.
About the conference
SpringOne is the annual conference for the global Spring community held in both Europe and the Americas. SpringOne Europe 2009 focused on the emerging technologies and best practices around the Spring Framework and enterprise software development. The event featured the project founders, core committers, authors, consultants, project leads, and professional trainers.
RelatedVendorContent
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
18 agile and lean practices for effective software development governance
Intrigued
by
Charles Abreu
Posted
Re: Intrigued
by
Rob Bygrave
Posted
Re: Intrigued
by
Luis Espinal
Posted
Re: Intrigued
by
Rob Bygrave
Posted
Bad presenter
by
Emil Vladev
Posted
Re: Bad presenter
by
Gerald Loeffler
Posted
-
What is he saying with "There is a very small percentage of systems that need remote transactions"? Is it true? Is the distributed transactions market over sold?
-
Mr. Höller sure knows what he is talking about - but, boy, is he boring. No jokes, no funny pictures, no funny stories - just slides with bullets - absolutely nothing entertaining. Yes, this is a technical presentation - but, if someone haven't notices, even technical presentation like this one are intended for people to consume. C'mon Jurgen - put some style in there - anything that can wake up some of the audience will do.
-
No jokes, no funny pictures, no funny stories
want edutainment?: try martin fowler. although not without substance, you won't find there the combination of breadth and depth of knowledge displayed here... and if you find a funny story about transaction management please do pass it on ;-)
cheers,
gerald -
> Is the distributed transactions market over sold?
From my simple world view you can break distributed transactions into 2 cases.
1. You want 2 phase commit across multiple DBMS/JMS Queues
2. You want transaction semantics across network calls (EJB 1 & 2 etc)
The way I see it Juergen did a pretty good job of talking about the first case - aka 2pc over multiple resource managers has a significant cost and other alternative approaches exist.
EJB 1 and 2 is a good example of the other case imo. That is, it tried to make the network transparent (remote EJB calls) and pretty much needed a transaction manager to ensure those remote calls could all together be treated atomically (~ Corba anyone?).
In my book the common alternative to EJB 1/2 remote calls approach is to use web services. Generally each web service call executes atomically by itself - aka you generally don't have a 'transaction' spanning multiple web service calls (you might use state transitions of the underlying data instead).
That's my high level view of your question anyway. I end up converting your questions to...
- When is 2PC over multiple Resource Managers (DBMS/JMS) justified?
- When making RPC type calls when is EJB justified over say individually atomic web services.
Hopefully that is an interesting/useful perspective.
Cheers, Rob. -
What is he saying with "There is a very small percentage of systems that need remote transactions"? Is it true? Is the distributed transactions market over sold?
You bet. It's always been. Most distributed systems are pretty much e-commerce sites or internal transaction processing systems, and in most of them (at least the ones I've seen), pretty much do local transactions.
Unfortunately, many of these systems set their connection pools to be XA connection pools, but they still end up using only one database, or if using multiple databases, their business rules get them to do transactions in each separately. It is very rare that you really have to set up a transaction to be committed as all-or-nothing simultaneously on more than one resource.
Blame it to software vendors and academia for forcing a theoretical white elephant that's only good for a narrow problem domain to the general IT populace :) -
Yes, I agree that 2PC has been 'oversold' (in the JEE world).
Vendors do tend to skip out the "... you don't want to use this feature in this scenario because...". IMO this is why presentations like this are important.
For me part of the 'problem' was that JTA it was a requirement of EJB v1 due to its remoting/distributed nature... so by default people would tend to use XA/2PC for their DB transactions. So 2PC wasn't always *sold* but came with the J2EE territory. I'm not sure how many developers/engineers thought critically of the implications but instead went with the flow.
6 comments
Watch Thread Reply