unicast delegate=(carefully)generalized func ptr

The delegate construct is related to func pointer, functor, java SAM interfaces … A beginner need not grasp all the relations but sooner or later we have to.

I feel delegate was invented much later and is a generalization of those predecessors.

http://bigblog.tanbin.com/2010/11/delegate-instance-2-field-heap-object.html is the best sound byte I have come up with. ** The 2-pointer construct is innovative. **

delegate element = 2-field heap object, internally

* A delegate instance is a 2-field HEAP object enclosing a Pair of pointers to 1) Target object 2) a method therein.
* A delegate instance is a 2-field HEAP object enclosing a Pair of pointers to 1) a method 2) its host object.

The method signature must match the delegate Type, which is not as restrictive as it sounds — The signature specified in you delegate Type is entirely up to you.

Caveat — this is a so-called simple delegate with an invocation list of 1. Focus on the core issues.
Caveat — the method in this delegate is non-static. Method can sometimes be static but we won’t cover it today.

Remember — a delegate instance is ALWAYS allocated on heap.

[1] is a very short description. Here’s the slightly longer version — At both runtime and compile time, we should view a simple delegate instance as a 2-field heap object enclosing
1) a pointer to a Target object
2) a pointer to a method therein.

In one part of the program, you pass in a target object (possibly “this”) + its method, to instantiate this delegate as a “wrapper” object. You then pass this wrapper around. Often this wrapper becomes a field of an observable object. The observable can then “invoke” this delegate which internally calls the target’s method.

SecDB – dependency-graph database

SecDB is an in-memory object database, just like gemfire. But Gemfire doesn’t have graphs; only standalone hash tables. Gemfire is credated by OODB (object-oriented database) veterans.

SecDB runs (in-memory) 24/7 with mirror sites and disk-persistence. No early morning cache loading like many trading systems do.

SecDB is, presumably, a master/slave database accessed over the network, just like a regular RDBMS.

This is internal low-level design so not many people would confirm, so here’s my personal speculation. For maximum flexibility SecDB probably uses dynamic object types in the python sense, not the static types in java. (Perl and javascript OO is also based on the generic hash). GS says SecDB is object-oriented, but I guess it’s not strongly typed. Perhaps less like struct-with-methods but more like python’s dictionary-based objects.

1) Here’s the Best way to start understanding secDB –
    Assumption 1 – we can build most FI trading apps using java.

SecDB is a schemaless graph database, like a huge xml. Each node represents a domain object, such as Trade, Position/Deal, Price, Product, a series of market data…

    Assumption 2 – operations are mostly CRUD i.e. create-read-update-delete.
    Assumption 2a – Most CRUD business logic are doable in java without RDBMS, using graph-walk.

SecDB can therefore implement the same logic using graph-walk.

2) Technical comparison against java + rdbms.
Data access is index lookup in RDBMS but SecDB requires deep graph-walk. Occassionally, in-memory indexing can improve performance. A gemfire index is a auxiliary hash table, so secDB may be similar.

3) functional comparison against java + rdbms.
Strength — time-to-market with a new “instrument”. Actually, “Product” is the buzzword used in GS. Using rdbms, we need table changes, application changes, impact analygis and regression test — rigidity.

Weakness — fast-changing data. SecDB is great for relatively static data. To update a tree node repeatedly, we probably need to walk the tree every time. But is disk-based rdbms any faster?
Weakness — equity — latency-sensitive. (But somehow JPM and BofA are using graph-DB for FX risk mgmt.) To address performance hit of graph-walk, GS throws in massive amount of hardware. GSS risk uses a compute-farm aka grid.

Strength — PnL Rollup is naturally a tree algorithm.
Strength — what-if scenario analysis exploits spreadsheet-style chain reaction
Strength — risk stress testing or scenario testing.     Risk is the most important user of SecDB.
Strength — UAT datatabase is the prod DB but in RO mode
Strength — real time pricing an instrument that depends on many other “objects”. You can give a what-if tweak to one of those objects and see the spreadsheet-style ripple effect. I think it’s because all these objects are in memory and listening to each other.

reliable JMS in various configurations

Simple Rule: In both queues and topics, I believe expiration setting overrides every delivery guarantee, including Durable sub. Idea is, sender knows its OK to drop a pending message after its useful life. See P101, 104[[JMS]]

Simple Rule: In both queues and topics, durable or not, non-persistent messages are always at risk to get lost[2] , so reliability is always below 100% — P102 [[JMS]]

[2] if broker acknowledges receipt to sender, then goes down, with the message. Persistent Messages are persisted before broker sends ack to sender, and sender method returns. Without receiving the ack, sender blocks for some time and throws an exception.

As we go though different configurations below, we will realize 100% reliability requires multiple conditions. Each missing condition can break 100% reliability.

– durable, persistent message without expiration? guaranteed
— same config but nonpersistent? not reliable
— same config with expiration? will expire

– p2p, persistent message without expiry, but a disconnected receiver? guaranteed — consider the SIM upfront queue.
— same config with expiry? will expire

– disconnected non-durable subscriber? won't receive
– connected non-durable subscriber, persistent message without expiration? best-effort. I believe broker will attempt delivery. If client disconnects before sending ack, broker may give up.

persistent messages may get delivered twice

Even though a persistent message is “delivered exactly once”, it can get delivered twice to a given receiver, if the broker doesn't receive acknowledgment in time. See P102 [[JMS]]. Failure could be in the broker or the client runtime.

If a trading system must receive each order message exactly once, there are many solutions.

* check the message redelivery flag, which is guaranteed to be set on 2nd delivery by the broker.
* check message id
* client_ack
* transacted message

thread detach — boost ^ java

In most (if not all) systems, a thread object is a “poor handle” on a real world thread.

in java, if the thread object becomes unreachable (and garbage collected) then you can't join or interrupt the thread, or test if it holds a particular lock. You have to wait for it to finish or pull the plug with System.exit().

Same scenario exists in boost thread. Additionally, boost lets you explicitly call myThread.detach(), to decouple the myThread object and the real world thread.

Q: after detach(), what's the thread object?
A: it represents not-a-thread