Posted by Ajay
Spring as a framework has made a lots of things much simpler for developers. Transactions is one of the area that Spring has simplified a lot. Have you ever wondered how the nitty gritty details of transaction worked in Spring? Well let me share some of what I learnt
What is a transaction?
A Transaction is defined as an indivisible unit of work. It always follows the ACID properties.
- Atomicity- all or none principle - complete the transaction in it’s entirety or do none of it.
- Consistency – do a drew brees (:-P ) - as you go from one state to another, data integrity should be maintained
- Isolation – transactions should not effect each other
- Durability – persistent state should be maintained.
A transaction can either end as a commit or a rollback.
Transaction models
There are many different transaction models available: Local transaction model, programmatic transaction model, declarative transaction model.
- Local transactions are resource specific, for example a transaction associated with JDBC. The local resource manager handles these transactions. With this model the developer will manage the connections to the transaction manager. JDBC transactions are controlled by DBMS’s transaction manager. The Connection object supports transaction demarcation. JDBC has auto commit turned on by default, so commit is done after each SQL statement executes. The problems with this model is that it introduces developer errors when coding the connection logic.
- Programmatic transaction model leverages JTA. The developer writes code to manage the transaction and not the connection as in the local transactions. The UserTransaction interface comes into play in EJBs and uses the begin(), commit(), rollback() functions. Spring uses TransactionTemplate to perform the same task with the execute() method that takes a TransactionCallback object. The main disadvantage of this method is that lot of responsibility rests on the shoulders of developers to make sure they handle the transaction semantics properly.
- Declarative transaction model is commonly known as Container Managed Transaction in the EJB world. The general idea behind this is that the container will manage the commit or rollback of the transaction, the developers will only to tell the container how to manage the transaction through configuration parameters – ejb-jar.xml in case of EJBs or ApplicationContext.xml in Spring. In Spring we use the TransactionProxyFactoryBean to implement this transaction model. EJB3.0 introduces the use of annotations for this transaction model. We also need to tell the container how to manage the transaction. This is done using a TransactionAttributeSource bean associated with a transaction attribute which has 6 different settings- Required, Mandatory, RequiresNew, Supports, NotSupported, Never
When do we use programmatic transaction model?
Usually programmatic transactions are useful when user we have client initiated transactions. If a client is making multiple remote service calls for a request, then transaction is maintained on the client side.
Another reason to use this methodology is if using JTA is very expensive in terms of performance. In such cases where we might need to squeeze every ounce of performance, so we might decide to use JTA only when absolutely required. This is called localized JTA transactions.
Another scenario is when there are long running transactions. In EJB’s these are handled using stateless session beans, where you might have multiple stateless session bean methods as a part of a single transaction.
For all other situation is is advisable to use the declarative transaction model.
JTS and JTA
Now we need to understand the difference between JTA and JTS. JTA is the interface developers use to manage transactions. The JTS or Java Transaction Service on the other hand is an underlying service that implements JTA and provides that to application servers. So essentially JTA provides the interface and JTS is the implementation similar to the relation between JDBC and database drivers.
Tags: spring transaction
Posted by Ajay
Another great session in the conference was a session on the way Apache’s community is organized. Any software community has the following different approaches
- benevolent dictator approach - the basic idea here is that one person develops most of the product, providing some degree of control to other users, but all code submissions goes through the single person. Linux development follows this model. It provides quick focussed development, there is no problem with bike shedding ( a concept where infighting on development methodologies can break up a group ), lower committer pool, new input and ideas are restricted by the dictator’s interest.
- going it alone - This provides each developer complete control, crystal clear development methodology. It has a higher chance of abandonement and burnout. Sourceforge uses this methodology.
- meritocracy - Apache Software Foundation uses this methodology. It follows a principle based on Rome. Very few people are citizens by birth. Most achieve citizenship through a merit based model, by performance in society like being a soldier or gladiator. This methodology focusses more on community and voting, allowing developers to get more responsibility based on their performance in the community.
The second day also had couple of interesting sessions on OSGI. One session was on how the Tuscany project used the felix framework to convert it to an OSGI based model. The session was informative in general, but it gave a general idea that there is too much of dependency hell that accompanies the conversion to OSGI. This could be a limiting factor in complete adoption of Felix.
Another very interesting session was that given by Sam Ramji about Microsoft’s path into Open Source. It started off with a funny crack on how Berkeley is known as the People’s Republic of Berkeley, simply because it is a huge melting pot. Microsoft has been instrumental in many open source projects, some of them include POI - Poorly Obfuscated Implementation, HBase - Hadoop Database, AMQP - Advance Message Queing Protocol, NetMon, Azure - Microsoft’s cloud computing alternative and a language called M. Microsft’s Cliff Schmidt has also been involved in a social project called Literacry Bridge project to help poor children to learn without a laptop. They have come with an idea of a talking book to introduce certain concepts. This project can be checked out at http://literacybridge.org. This was an interesting session but still raises the question as to whether Microsoft is truly open source by heart?
Tags: apache con
Posted by Ajay
Finally my first Apache CON conference, I had looked forward to this day for a long time. Practically the newest frontier for open source development. As tremors of excitement ran down my spine I drove down to New Orleans to attend my first ApacheCON conference. The conference was held at the Sheraton in New Orleans, a nice place but a pretty ordinary view except from the front.
The Sheraton
The Sheraton
And of course i there were some quirky signs that I liked a lot like this for example
Now let me summarize the sessions that I attended, possibly some areas that might lead to potential posts in the future
Apache Security
Apache Server is one of the more reliable HTTP servers. Security of this server is quite an important consideration. Some configuration tips on Apache
- try to write your own configuration files from scratch.
- use CURL/wget and write a test scripts to see if it does what it does.
- Try to avoid conditionals like <IfModule>, if a module is not needed dont enable it
- Limit number of writable directories. tmp can create security loopholes. ChRoot, FreeBSD jail, Solaris Zones can limit what a socket can do. It create a sandbox that is accessible. Netboot servers can be used.
- Block outgoing connections
- minimize incoming connections to port 80 or 443, use bastion and ssh or sftp
- use firewalls. MOD Security is a web application firewall inside apache. It uses Rule based request filtering.
- GRANT ALL PRIVILEGES is a bad word, separate schema definition from application security code
Some reference books for Apache Security
- RYan C Barnett - Preventing Web Attacks with Apache
- Ivan Ristic - apache Security
Web Application Security
This was a great session given by Christian Wenz. Did you know that 9 out of 10 websites have security vulnerabilities? An interesting quote from Christian - “Security is like brushing your teeth”…..funny quote but quite so accurate about security. Security breaches can occur due to the following reasons
- bad advice
- lack of time
- new server API’s provides endpoints with new risks
A traditional model of web applications had both model and controller on the server side, but with AJAX based applications, more area is exposed to risk since now the controller is moved to the client side of things.
An old and persistent problem is Cross Site Scripting or XSS. With Javascript and Ajax, now potential intruders can access user cookies through javascript code, which can result in access to session ids. Login forms can easily result in XSS. The best defense is to handle characters like < > ” ‘ &. The best advice is to not blacklist using all possible combinations of the characters but rather to try to eliminate all occurences of the previous problematic character set.
Cross site forgeries is another type of security issue that can crop up. HTTP server sends HTTP request that does not happen voluntarily. Victims may be attracted to some website. The website will send you a form and javascript which is similar to some other website. This form is then redirected to some other website so that the attacking website gets a request from a user that can be used to forge the users’s identity. Some solutions are
- users should logout as soon as possible
- never visit unknown sites
As a developer you can do the following to thwart cross site forgery attacks
- request login before critical operations
- include secret/random tokens in the form
- use random names for form elements
Who hasnt heard of SQL Injection, a potentially dangerous form of security attack that can hit the database part of your application really hard. One suggestion to thwart SQL Inejction attack is not to create a blacklist for all combinations of attack patterns, but instead use database specific methods like PreparedStatement to do the same task.
Javascript hijacking is an attack category that has been introduced by the wide spread use of AJAX and Javascript. Server backends many a time return data as JSON format. Sometimes array constructors can be overriden and offensive data can be written into it. Solutions - use POST API, demand a certain HTTP header like Content-type:application/json.
The two general rules to thwart most security attacks
Rule #1: Validate all inputs
Rule #2: Escape all outputs
This was the core of the security sessions on Day 2. In my next post I will summarize some more sessions that I had the oppurtunity to attend.
Tags: apache con, security
