What happens here is that the BMW instead of the expected fancy 19 inch wheels ends up having Trabant size, 13 inch, wheels (not that the car looks odd, it just won’t go far). If a unit test does not cover this scenario (there would rather be coverage for a simple scenario with one car, as I don’t believe in perfection of the testing code), the bug may slip into production.

However, this problem can be easily prevented/fixed by introducing immutability.

This will force a user of the Wheel class to create a new instance every time instead of reusing existing object if a different configuration required.

Note, the code becomes slightly shorter as well.

Just to answer a question why don’t we do the same with the Car class and leave the `add` method? – The reason we don’t need to do this is because the internal state of the car is managed via the Car class interface only. However, be careful if a Car instance may be a non-root part of a different objects hierarchy.

1. Load main objects with lazy batch loading of one-to-many associations. One long query for the main objects and multiple (sub)queries for the associations.

2. Load main objects with eager loading of one-to-many associations using join fetch, which means executing single complex query with many outer joins. The performance of such a query, query execution without fetching, is quite poor (20-30 seconds in my case), but it’s only one query.

One obvious thing to do since we need to deal with a very big number of records (it means we can’t load everything into memory first and then start processing), is to fetch data via scrollable cursor with some batch size, e.g. 100.

Unfortunately, both approaches have their drawbacks. First approach with regards to the amount of data will execute many queries to fetch associations, say, 1000 000 / 100 (batch size) = 10000 – this is 100 less, but still lots! In this case, execution time was around 45 minutes (including transformation and putting into cache, but this phases’ time is neglectable).

Second approach is way better in terms of the number of queries (there is only 1! query to execute), and we would expect some significant performance improvement. However, the number of rows to load will be about same, and if we look closer, the amount of data to load and to process by Hibernate is much bigger, because every row will have column from all joint tables: if main table has 10 columns, all 10 values will appear in a row for each combination of associations. Though, in practice this approach showed some improvement, it was insignificant – it ran in around 30 minutes.

I simply could not accept this very suboptimal performance. So I came up with one more idea… and it was not about abandoning Hibernate and implementing everything with pure JDBC. The third approach is to have one query per object type: one query for main objects and one query for each of one-to-many associations – in total 5 quite effective select queries. All these queries should be executed one by one in the beginning and all 5 scrollable resultsets should be processed kvazi-simultaneously in one go. To achieve this, one important requirement should be met by all the queries: they should be ordered by the same key (id of the main object) and have the same set of filters as in the first query. In this case, hibernate mapping of associations is lazy, so we need to take care of populating them in our code while going through the resultsets. This process is illustrated below:

Using this approach the full bulk loading took only, get ready… 4 minutes! This is due to the data being loaded in an optimal way in terms of amount of data, number and complexity of queries, and number of network round trips.

I still like PHP for its simplicity of deployment and management – just copy files and voila! And for simple webapps you need the cheapest web hosting like the one I have to host a WordPress installation for this blog. Everything simple and easy, but… sloooow! I mean, being restricted to FTP access (normally, you don’t get SSH access with a cheap PHP hosting) only, transfering files and later managing them can be tedious and ineffective. Fortunately, there’s a bunch of file management application (written in PHP) that can help you in performing file tasks. But they use your disk space, can be slow and require to much clicking with often page refreshes… So, ideally would be to have that silver bullet SSH access (though it’s not ideal as you may not be able to use SSH from everywhere). Just compare, what is faster: to type “cd …” and “rm …” (“unzip …”, “untar …” etc) and press ENTER, or to click through the tree of files with page refresh between each, or even worse – to perform file manipulations via FTP? For hackers like us, the answer is obvious – CLI.
So, I though it could be easy to create a web command line application that would execute system commands in my hosting environment… This thinking resulted in a simple and very lightweight PHP application that gives me all I need in terms of file management on my php hosting – it’s called quick-shell. Besides that it offers easy ajax-based file upload into a current directory (implemented with jQuery AjaxFileUpload plugin) – so you can do pretty much everything from your browser. Feel free to download/fork it from GitHub, use it and let me know how you find it.

P.S. Very important! Don’t forget to create .htpasswd file with your password to protect your files from anonymous access.

Let’s store it in a relational database (e.g. MySQL). For this we need to create a table:

And you need to show it in a tree view, e.g.:

You can see that comments added in an arbitrary order (by looking at the comment id sequence).

So how are you going to select all the data to build the tree by SQL means? Standard SQL does not provide hierarchical select feature (like Oracle’s CONNECT BY). One would probably end up doing multiple queries, which sounds like a very inefficient thing to do (imagine fetching a 10-level depth tree of 1000 comments). Fortunately, there is a better idea. I would say even more: a solution with one simple select query! Excited? It’s very simple, actually.

The idea is to construct a select statement which will return results sorted in an order we need (say, in the tree above each node is a row in the query result set). On the other hand it is very similar to the structure of directories and files in the filesystem. So, we will use a property of files here, which is the path. When creating a new Comment instance we will set its path, and update when setting a parent Comment:

If we apply this transformation to the example above the data in the table will look like:

Now we can use the path field to retrieve our comments ordered accordingly. By executing

we will get this:

The rest is only a matter of formatting the results in order to get nicely looking comments tree output. (Note: the level can be computed as a number of slashes, ‘/’, in the path string).

Also, when using ORM like Hibernate (or JPA in general), you are not forced to use SQL and can get your job done with simple criteria-based or HQL queries.

As a free bonus, you get pagination working properly without extra tweaking as you would have to do in case of multiple queries.

P.S. One piece that is missing in the above example is that the sorting for strings based on numbers will be done in the alphabetical order, e.g. 11 will appear before 2 (which is obviously not what we want). So to fix this problem you can prefix each part of the path with a length of the numbers in characters. It will result in smth like: 12, 211 (or 1.2, 2.11)…

First of all, query plans are not cached on the client-side (it would be a bit foolish, because it would not give any performance boost, because we would have to send the query plan over the network each time before execution, and it contains more structured information than just a SQL string).

The parsed query plan is only stored on the server side, in a common session cache, so all sessions can reuse it. This comprises the biggest part of queries optimisation by the database server (in terms of usage of both CPU time and memory).

What is cached on the client side? – It is an identifier of the parsed query (cache then looks like a map of [sql => id]). Another big difference from the server-side cache is that the client-side cache of prepared statements resides in scope of a session (connection). (I’m not sure about the rest of the JDBC drivers, but in the Oracle implementation query parameters are also cached, which would create a memory “leak” problem when pooled connections are actively used for some period of time, hence they don’t get closed, and the cache doesn’t get released.)

In general, the prepared statement execution looks like (in terms on commands sent to the database server):

1. id = PREPARE (sql) <- here on the server there will be an attempt to get the query plan from the cache.
2. EXECUTE (id, params1)
3. (optional) EXECUTE (id, params2) …

You can see that PREPARE for the same query is executed only once throughout the session (the lifetime of the connection). Considering that in most scenarios connection pool is used, it allows you to save relevant amount of time by not performing an additional PREPARE request on the network before each consecutive EXECUTE.

Optimistic locking is like leaving the door to the toilet open: you have a number of toilets, select one, and you are optimistic that nobody will come to use the same toilet, too. If someome comes, it will of course be embarassing, an exception is raised, and he must abort his try, but you hope that these conflicts are the execption.

Pessimistic locking is like always locking the door to the toilet: although there are a number of different toilets, you are expecting every time that somebody else will come to use one, too, and that the only safe option is to lock all toilet doors (which corresponds to page locking). If someone comes and wants to use a toilet, he cannot enter and must wait before the locked door.

Found at Optimistic vs. Pessimistic Locking.

Installation:

• Create /etc/yum.repos.d/mod-pagespeed.repo yum config file for mod_pagespeed with the following content:
  [mod-pagespeed]
  name=mod-pagespeed
  baseurl=http://dl.google.com/linux/mod-pagespeed/rpm/stable/x86_64
  enabled=1
  gpgcheck=0
• Then install mod-pagespeed:
  yum install mod-pagespeed
• Restart httpd service to get it all working:
  service httpd restart

Later, I will update this post with the comparison of performance with and without mod_pagespeed (with lori add-on).

And here’s the solution:
1) in server code

(in Grails terms meaning: don’t render the ‘src’ attribute if the url is empty)

2) in client (javascript) code:

So first, never ever leave your ‘src’ attribute empty! And second, never ever set ‘src’ value to empty string programatically or by any other means. Third, it’s ok to do this when it’s officially fixed either html5 is fully supported by all major browsers (hopefully).

Have a good one!

2. Install Tomcat by copying and unzipping an archive:

3. Create a service configuration for Tomcat 7:

4. Verify the service config with commands:

5. Configure an AJP connector in $TOMCAT_HOME/conf/service.xml:

If you don’t want your Tomcat to be exposed for direct HTTP requests comment out HTTP/1.1 connector section.

6. Configure Tomcat to respond to the supersite domain (e.g., supersite.com):

7. Update your mod_jk to the latest version by getting an appropriate for your system mod_jk*.so file from http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/:

8. Create a new domain (supersite.com) using Plesk panel.

9. Configure your Apache to use mod_jk for the supersite domain:

Then execute the following to ask Plesk to include your new vhost.conf into httpd.include:

Create jk.conf:

Create workers.properties in /etc/httpd/conf:

10. Restart Apache:

11. Deploy you application to Tomcat by copying war file to /home/supersite/tomcat7/webapps. You can also deploy your application as a ROOT application by either renaming the war file to ROOT.war or replacing content of the existing ROOT directory with the war content.

12. Verify if the Tomcat it responding by going to http://supersite.com (also verify http://www.supersite.com).

13. Check Tomcat logs in $TOMCAT_HOME/logs/catalina.out if your application failed to start. This will help to diagnose a possible issue with the application itself.

TaskMonitor – the ruthless and thread-safe killer.

ExecutorService provided by java.util.concurrent package.
And now putting it all together we have got TaskExecutor:

Leveraging capability of Future to hold task execution result (of type T), we could eloborate and arrange collection of the tasks execution results. To achieve this, you would replace usages of Runnable with usages of Callable and implement appropriate logic to store the outcomes.