Discussion of software development problems from the highest level of abstraction

Testing of JavaEE Applications with Arquillian

Consider following trivial JavaEE application:


Sample JavaEE application with module FooBean we want to test

We want to test FooBean. However FooBean uses database or a distributed cache (e.g. Infinispan) or even another EJB bean. I.e. it depends on expensive component.


Optimistic vs Pessimistic Locking in JPA

Issue Optimistic Pessimistic
Deadlocks No
execution goes straight without locking anything in database. Execution may fail if a concurrent thread modified the same record  ( OptimisticLockingException will be throw in this case)
database-level locks are acquired and hence deadlock may occur
Transaction Span Temporal and spatial span
entity version could be conveyed to client which can hold it as long as he wants. This allow a virtual transaction to span both temporal and spatial. Only during commit version check will be enrolled to ensure data integrity
No span
it would be a suicide to hold a database-level lock on an entity which is edited by client remotely. This would quickly exhaust all system resources. As such no transaction span is available
Changes Overwrite No
changes made to an entity in another thread are detected and transaction is aborted – this prevents unwanted overwrites
changes made to an entity in another thread are not detected – they are simply overwritten (last change wins)
Changes in Tables Required
need to add column into each table for storing a version counter  ( javax.persistence.Version)
everything needed is provided by database itself
Performance Better
doesn’t require and database interactions – recommended for web apps which must scale
requires explicit locking in database which is expensive




glClientWaitSync vs glWaitSync

Another couple of OpenGL commands which is hard to distinct is glClientWaitSync​ and glWaitSync​. Below are mnemonic helpers to get the distinction.


glFinish vs glFlush

Had always a problem to remember a distinction between glFinish and glFlush calls. To fight the issue I’ve created two pictures which serve as a mnemonic helper.


Traits of Some Sorting Algorithms

It’s quite common to ask during interview on developer position about traits of sorting algorithms. I’ve summarized this information for some of the most known algorithms.

List of traits:

  • time complexity – how much time does it take to sort input data in terms of O notation? The less the better
  • stability – does algorithm preserve relative order of elements if they share the same key? Stable algorithm preserve this order while not-stable typically mess the elements
  • adaptability (or naturalness) – how algorithm behaves on sorted (or partially sorted) data? Adapted algorithm benefits (in terms of runtime) from data being presorted, i.e. they require less time to sort such data
  • memory complexity – how much additional memory is required to sort input data in terms of O notation? Some algorithms performs its job in-place, some require temporary storage to keep interim results. The less the better
  • locality of reference – determines the manner algorithm accesses initial data: does it jump over the data or tends to use sequential access? For CPU its better to access data sequentially since it keeps caches warm
  • parallelization – is it possible to use several threads to implement algorithm? I.e. does algorithm allows to use “divide-and-conquer” strategy to effectively split work between several CPU cores
  • linked list – is is possible to use this algorithm on linked lists? Typically data for algorithms is passed as arrays but sometimes one need to sort data sorted in linked list