real world DB deadlock reduction — insert hotspot

One of my multi-threaded java apps (using ExecutorSerivce) started getting database deadlocks when I increased thread count from 1 to 5.

* In Dev/Test environment, i got up to 4 deadlocks out of 20,000-40,000 inserts.
* In Production, I got 3000+ deadlocks out of 20,000 inserts.

Solution: I changed the clustered index from the table’s identity col to an AccountNumber column.

Result? down to below 5 deadlocks.

Analysis: Probably the clustered index on identity col created a hotspot for inserts. Since new rows all get similar identity values, all 5 threads need to write to the same data pages (sybase defaults to page lock). Each thread (with its own db connection and spid) in the deadlock probably writes to 2 pages within on transaction. If one thread already wrote on page 1 and needs to write on page 2 before commit(), but the other thread already wrote to page 2 and needs page 1, then this scenario meets

* wait-for circle
* incremental lock acquisition
* mutex
* non-preemption


financial jargon: buy-side, sell-side

The split between the Buy and Sell sides should be viewed from the perspective of securities exchange services. The investing community must use those services to trade securities. The “Buy Side” are the buyers of those services; the “Sell Side” are the sellers of those services.

Sell side brokerages are registered members of a stock exchange, and required to be market makers in a given security. Buy side firms usually take speculative positions or make relative value trades. Buy side firms participate in a smaller number of overall transactions, and aim to profit from market movements and accruals rather than through risk management and the bid-offer spread.

In Short the entity paying the commission on trade would be a buy side and the one receiving it is a sell side.

threadpool && GUI examples, showcasing anon class

Get used to this kind of coding style. In this case I don’t see a good reason for the anon class. It’s more readable to pull it out into a named static nested (or top-level) class.

However, in real life the anon class’s methods often need the variables in the enclosing class. Anon is quick and dirty.

public static void main1(String args[]) {
new ScheduledThreadPoolExecutor(1).scheduleAtFixedRate(new Runnable() {
public void run() {
System.out.println(new Date());
}, 0, 1000, TimeUnit.MILLISECONDS);

// Now see the same pattern in this GUI code:

ActionListener taskPerformer = new ActionListener() {
public void actionPerformed(ActionEvent evt) {
//...Perform a task...
new Timer(delay, taskPerformer).start();

sorted linked list #TreeMap

In 2009 I was asked about a sorted list’s performance of
* add()
* find() by key
* return all elements in sorted order

These operations are equally frequent.

I could only think of 2 types of sorted list(???)

  • LL) sorted linked list
  • AL) sorted array list — based on an expandable array
  • How about 3) linkedHashMap where the value is either a count or a linked list of the identical objects.
  • Now I think a TreeMap keeping count of duplicates is best. It looks like a list !

FIND will be slow for LL — no random access, so this is not suitable.

AL’s add() requires O(log(n)) to locate the position to insert, but also O(n) to shift lots of existing occupants. Average shift complexity is n/2 i believe. By the way remove() would also require shifting.

const ^ input iterator – unrelated

(It’s probably enough to know when to use each… Tbudget?)

A) input iterator is a fwd iterator for input streams — P802 [[Absolute C++]] (This book has concise coverage of const and input iterators)

B) const iterator is modeled on ptr-to-const, so you can’t make *myIterator a LHS

These 2 are unrelated.

Are these real (template) classes? dummy types or typedef? I feel in general you can’t say for sure, so I assume the lowest common denominator — dummy types. Note const_iterator is a nested Type in container class declarations, but still it can be a real class, dummy type or typedef.

every python thingy is an object with a type #del

I like this particular insight in [[py ref]] (i.e. “python essential reference”) though I can’t easily verify it in code — Every thingy in a python program is an object with a type. (There might possibly be some exceptions but this is a rather good starting point.)

* An object is defined, same way in C++, as a storage_location, with an (obviously) immutable address.
** content could be mutable.
** Even an int is an object, unlike java

* Every storage_location (Say ObjectA) has a specific data_type. Required by python interpreter, java compiler or c++ compiler… That specific data_type is technically a Type OBJECT.
* [[peref]] made it clear that Type tells us the features supported by this storage_location. Features include methods and fields…

The thing about the python language is that Everything seems to be an object with a type. Here are some special objects and their types
$ a free function. This OBJECT has a __name__ attribute. Try qq/dir(len)/
$ a bound instance method. Such an OBJECT has an im_self attribute.
$ a bound class method. Such an OBJECT has a __name__ attribute
$ (There’s no such thing as a bound static method — nothing to bind.)
$ a regular instance method. Such an OBJECT has a __self__ attribute pointing to the host OBJECT
$ a regular class method. Such an OBJECT has a __name__ attribute
$ a regular static method. Such an OBJECT has a __name__ attribute

Warning — these special objects each have a distinct data_type but not by type()! It’s worthwhile to step back and recognize these special OBJECTS as separate data_types with their own features. The “feature set” difference between any 2 data_types is reflected in various ways (such as the attributes…)

* the built-in type() function is an almost-perfect way to see the data_type of a storage_location, but I don’t think it reveals all the details I need in a foolproof way.
* The “type” OBJECT is comparable to type_info objects and java “class” objects.
* What’s the type of the “type” OBJECTS? We don’t need to know.

1st learning note on option sensitivities – 3 Greeks

— delta — relation to current asset price, assuming out-of-the-money[5] —
Assuming a call with strike above current asset price, out of the money, call premium rises along with current asset price [3]. It feels like becoming more volatile/dangerous. Dangerous to the insurer.

[5] insurers make sure most of the time they don’t have to pay the claim

Assuming a put with strike below current asset price, out of the money, put (insurance) premium drops when current asset price moves higher and AWAY from strike price.

For out-of-the-money options, both call and put, when asset price moves closer to strike price, insurance premium escalates.

– A put writer (insurer) guarantees to buy our asset at a sky-high strike price. The insurer wishes asset MV to appreciate, so a depreciating MV means higher risk, higher premium.
– A call insurer wishes asset (eg oil) to depreciate, so an appreciating asset means higher risk, higher premium.

[3] Same thing if the call is in deep the money. Rising asset price further protects the buyer because the call is almost guaranteed to be in the money at expiration

— vvvvv vega — relation to vvvvvvol —
Vol increases option payoff; Vol makes options more PROFITABLE, as it’s more likely to hit the strike price. Stable securities have lower “insurance-premium”, as strike is disaster for the insurer.

Q: But what if the option we hold is already in-the-money? I read that higher vol always increases our valuation, but higher vol would increase the chance of going out-of-the-money?
A: I feel in this case high vol’s positive impact outweighs that particular negative impact. Positive impact is the increased chance of sky-high payoff.

— relation to strike price —
call valuation (ie insurance premium) drops with higher strike price, because it requires more volatility to hit it.

call valuation rises with lower strike price, because the strike is dangerously close to current price. As if more volatile.
put valuation drops with lower strike price. If you exercise, you sell the asset for less money — The simplest explanation.
put valuation rises with higher strike price. If you exercise, you sell the asset for more money — The simplest explanation.

— ttttt theta — relation to tttttime-to-expiration — decay of option valuation
For both calls and puts, longer time frame increases insurance premium, as asset has more “opportunities” to hit strike price.

If we hold a call or a put option, each day’s passage decreases our market value, AS IF vol drops.

servlet filters — possible uses

usage: add custom headers. both request and response. custom headers are flexible and powerful communication devices. X-ZED headers.

usage: standard logging on selected requests. You can add this filter to any number of servlets.

usage: time logging. end-to-end roundtrip
usage: request translation. response too.
usage: response compression
usage: consistent cookie processing and logging
usage: authentication and single-sign-on
usage: consistent look and feel?
usage: spell checker?