Posted by Ajay
Servlets in Brief
A Servlet is a Java technology that allows a container to generate dynamic content. These containers are called servlet containers. Tomcat is one good example of such a servlet container. The basic Servlet interface defines a service() method to handle client requests. The web container handles concurrent requests to the same servlet by concurrent execution of the service method on different threads. A servlet will also have a variety of methods like doGet, doPost, doPut, doDelete and doHead which is a specialized version of doGet returning only a header. The use of a SingleThreadModel interface will guarantee that only a single thread will execute in a given servlet’s service method.
Most Java web frameworks build on the Servlet API and require configuration of Servlets, Filters and Listeners. The JSR 315 will be a part of Java EE 6
Some of the proposed changes
- Support for continuations. The general idea of continuations is that you can save the current state of an object and return back to the saved state at a later point of time in your execution lifecycle. It is almost like taking a hiatus from your hectic work schedule, going on a trip around the world and coming back to find that everythingis as you left, no catching up, no making up work, just consitnue on as you were before your hiatus, how cool would that be. This is a concept that was popularized by Scheme and also is a major part of Jetty as Jetty Continuations. Now with JSR 135, the request object will now have a suspend() and resume() to suspend and resume execution from a later thread.
- Plugability - Today all deployment artifacts are defined in web.xml, which can at times just become large and unmanageable. So multiple frameworks can lead to having us define all the servlet mappings in this web.xml file. But imagine if each framework coems withit’s own web.xml that defines only the components that framework needs, and if we leave the job of assembling the components together to the container, our task would be so much easier, and our project would be so much easier to maintain. This spec introduces web fragements that does exactly this task. In addition to this kind of plug ability the new JSR also provides a feature where servlets can be inserted into the container dynamically at runtime using the servletContext.addServlet() and servletContext.addServletMapping(). One drawback of this feature is that there could be potential security risks since JARS can register their own servlets.
- Annotations - I am sure many of you are familiar with annotations, a technique to try to eliminate configuration files by introducing the configuration details in the source code file. JSR 135 introduces POJOS for servlets, so no more extending from HttpServlet. Just use the annotation @Servlet(urlmapping = {’mapping‘}, name=“abc” } and then use @GET, @POST, @PUT, @DELETE, @HEAD. Servlet Filters are defined using @ServletFilter and @FilterMapping. Unfortunately this Annotations methodology is not as hunky dory and cool as it looks, there are lots of potential problems that Roy van Rijn has mentioned on his post on theserverside.com which include potential issues with having two methods with the same annotations like @GET, there are no IDEs that are setup to detect Servlet using annotations. Also with annotations what we lose is that previously we could just override the methods, now you cannot do that.
- Programmatic entry - Potentially there might be support for programmatic login and logout as part of the HttpServletRequest and HttpSession.
- HttpOnly Cookies - Ability to prevent client side scripting code from getting access to cookies by defining HttpOnly cookies.
References:
http://www.theserverside.com/tt/articles/articles.tss?l=PonderingAboutJSR135
http://weblogs.java.net/blog/mode/archive/2008/04/servlet_30_jsr_1.html
Tags: jsr 135, servlet
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
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
Posted by Ajay
One fine day I was looking into the object persistence architecture we utilize in my project. We use a simple Hibernate based persistence, connecting to our database through JDBC, using JDBC’s transaction semantics. Then i came to thinking is there any advantage of using JPA over Hibernate as opposed to plain old Hibernate. Here are some of my thoughts. Let me start off by talking about persistence, hibernate and JPA in general.
What is persistence?
The general idea behind persistence is to extend an object’s life span. There are technically many ways to implement this. A simple way is to simply store the object as a file on the disk and then convert it back into an object, a good example of this is persisting objects as XML. Another alternative is using a database to store the data. The decision on which kind of persistence to implement basically depends on the kind of functionality that you need to implement. In my project we use both database based persistence and file based persistence (we use XStream , which is again a story for another day)
Let us consider persistence with a database perspective. Traditionally databases follow a relational paradigm. A Table is the main actor and is related to other tables through a relation. But an Object on the other hand compromises an entity along with methods that operate on the entity and it’s association with other entities. This has led to an object relation impedance mismatch which makes it tough to convert between those two.
Say hello to Hibernate and JPA!!
Hibernate has filled this void albeit not perfectly but enough to do the job. Persistence frameworks
is the key behind object relational mapping. Hibernate so far used to do persistence with it’s own Core API. EJB 2.1 was on the wane, a bloated technology, losing it’s grandeur, then came the redesign and scripting of a new reign of a new technology, EJB 3.0 specification that provided the JPA specification as it;’s answer to the entity beans of old. Hibernate 3.0 has to adapt to this changing world and adopted the JPA specs as it’s own.
JPA essentially provides a POJO based persistence model. It replaced entity beans which had the following problems:
- too heavyweight and coupled to the application server itself
- difficulty in deploying and unit testing
JPA essentially provides a standardization to the persistence methodology. Thus allowing any persistence framework to be used underneath JPA without having to worry about too much configuration. Hibernate implements the JPA specification by creating a wrapper over the Hibernate Core. This wrapper can be further made more effective by introducing annotations to take out some of the responsibility of the configuration file.
When thinking about the JPA specs, we introduce Hibernate EntityManager which is used to define the JPA life cycle rules for persistent objects, and is used as a wrapper around HibernateCore. The advantage of using JPA is that it brings with it some portability when having to switch between application servers that support JPA, which may not be possible with a Hibernate based solution.
JPA has many components that can be somewhat mapped to Hibernate:
EntityManagerFactory –> SessionFactory,
Persistence class creates the EntityManagerFactory,
EntityManager –> Session,
Query –> Query,
EntityTransaction –>Transaction.
It only needs a persistence.xml in the classpath which configures basic hibernate connection properties.
Everything else is managed through Annotations (for ex. a PersistenceContext injects a EntityManager object into the bean).
The advantage of using Hibernate with JPA is that you can enabled several features of Hibernate without having to mess with the JPA configuration like for example a second level hibernate cache. In addition to this you can use native hibernate mapping and API, the only problem with this is that if you decide to use a different JPA provider, it’s gonna get dirty.
Ex 1: If you want to export the schema programmatically, then use a Hibernate Ejb3Configuration()
that can easily replace the EntityManagerFactory, which can yield a AnnotationConfiguration that can
be passed into the SchemaExport instance.
Ex 2: Use the SessionFactory if you need programmatic control over the
second level caching. This can be done by fist casting EntityManagerFactory into
HibernateEntityManagerFactory and then extracting the SessionFactory.
But using JPA also has some disadvantages
* no control over cascading behaviour
* no indexed collections,
* Hibernate provides Filters and Caches
* no collections of primitive values
How useful would JPA be for me in my project?
This is an interesting question. One reason for the shift to JPA could be the standardization aspect, with increased portability. Now we no longer need to worry about moving to a different persistence provider like Hibernate or JDOLink, a concept called pluggable persistence providers. Now the question do I need it for my work? Is it worth sacrificing some of the features of hibernate like cascading and indexed collections for a standardized interface. For now i dont think so, but in the future if we decide to move to a full fledged application server like JBoss, most likely.
Some reference links for this particle post
http://asrijaffar.blogspot.com/2007/01/native-hibernate-vs-hibernate-jpa.html
http://maestro-lab.blogspot.com/2007/09/coding-java-persistence-jpa-vs.html
http://www.javaworld.com/javaworld/jw-07-2008/jw-07-orm-comparison.html
http://clarkupdike.blogspot.com/2007/01/hibernate-mappedby-to-superclass.html
Tags: jpa, persistence
Posted by Ajay
For the last few months I have been looking at performance improvements for my application on multiple ends. One is at the GIS end and the other is of course the database end. Caching is a great way to provide the performance improvement. Caching on the GIS end was an interesting exercise I implemented, which is a story for another day.
Today let me pen my thoughts on improving performance at the Hibernate level. Hibernate has many performance improvement techniques, of course we have implemented a small sub set of that for our task. Let me first talk about Hibernate’s performance improvement strategies. If you want to take it all in at a glance, take a look at this mind map image (maybe click on it to enlarge it)
First we need to understand that
- Sessionfactory is an immutable thread safe factory that initalize JDBC connections, connection pools and create Sessions.
- Session is a non thread safe single unit of work that represents a transaction
Caching, a blessing in disguise
Caching reduces traffic between the database and application by conserving data that has already been loaded into the application. Caches store data that was already fetched so that multiple accesses on the same data takes lesser time. Essentially caching reduces disk access, reduces computation time and speeds up response to users.
Hibernate uses three levels of caching.
- Level 1 mainly caches at the Session level
- Level 2 cache does it as the SessionFactory level.
- Query cache
Hibernate uses Level 1 cache to mainly reduce the number of SQL queries. It is always the default cache. If there are several modification on the same object it will simply generate a single SQL query for this. The level 1 cache is usually restrained to be for a single session, it is short lived. Essentially the general idea behind the fist level cache is that it batches queries.
A Level 2 cache is designed to interoperate between sessions. Level 2 cache is usually recommended when we are dealing with read only objects. It is not enabled by default. It is conceptually a map that has the id of the object as the key and the set of attributes the entity has as the value.
The Query cache is not on by default either. It uses two cache regions -
- StandardQueryCache - stores the query along with the parameters as key to the cache region. So any subsequent queries with the same key will hit the query cache and retrieve the object from the cache
- UpdateTimeStampsCache - tracks the timestamps of the most recent updates to particular tables to identify stale results
Remember all this caching will only be effective in reducing the number of queries if we use session.get to load the object. Using HQL to load the object may in fact create more queries.
Hibernate has four basic types of cache providers-
- EHCache - fast, lightweight, read-only and read write caching support,memory and disk based caching , no clustering.
- OSCache - read only and read write caching, memory and disk based caching, clustering support via JMS or JavaGroups.
- SwarmCache - cluster based caching based on JavaGroups, read only and nonstrict read write caching, usually used when there are more read operations than write.
- JBoss TreeCache - replicated and transactional cache.
- Tangosol Coherence Cache
The caching strategy is specified using a <cache usage = “”> tag. The caching strategies maybe:
- read only - for frequently read data, simple, best performer.
- read-write - data needs to be updated, never used if serializable transaction isolation level is needed, need to specify a manager_lookup_class in JTA environment.
- nonstrict read-write - rarely updating data , need to specify a manager_lookup_class in JTA environment.
- transactional - only used in a JTA environment
If the hibernate.cache.provider_class property is set, second level cache is enabled. Cache can be configured within hibernate.cfg.xml. Cache’s usage patterns can be defined within the <cache> element in the hbm’s associated with each domain class. Enable query caching by setting hibernate.cache.use_query_cache to true and call the setCacheable(true) on the Query object. Query cache always uses the second level cache. The Cache is loaded whenever an object is passed to save(), update(), saveOrUpdate() or when retrieving objects using load(), get(), list(). Invoking flush() will synchronize the object with the database. Use evict() to remove it from cache. A CacheMode defines how a particular session interacts with second level cache -
NORMAL - read and write to cache,
GET - read but dont put,
PUT - write but dont read,
REFRESH - force refresh of cache for all items read fromt he database
Fetching strategies
A fetching strategy identifies how hibernate will fetch an object along with it’s associations once a query is executed. There are four types of strategies
- Join Fetching - All associated instances are retrieved in the same SELECT using OUTER JOIN. But having too many of this can result in a huge chunk of the database coming into memory, cause performance hurdles there.
- Select Fetching - This is the default strategy. A second SELECT retrieves associated entity or collection. This is usually lazy unless specified otherwise. This is extremely vulnerable to the N+1 select problem, so instead the join fetching can be enabled.
- Subselect fetching - similar to select but retrieves associated collections for all entries fetched previously.
- Batch fetching - optimization on select fetching where a batch of entities are retrieved in one select
As far as we are concerned, we pretty much use EHCache as our caching strategy and do a lot of join fetching / lazy select fetching based on our requirements.
Of course all these technical ideas are borrowed from these websites
http://acupof.blogspot.com/2008/01/background-hibernate-comes-with-three.html
http://www.devx.com/dbzone/Article/29685
http://www.hibernate.org/hib_docs/reference/en/html/
Tags: hibernate, java, performance
