generic trigger Q&&A

Q3: explain the important term “trigger-event”, in relation to “trigger-action”

Q: can a trigger-event invoke both a before-action and an after-action?
A: yes

Q: can a trigger-action be defined with select-statements alone? Does it make sense?

Q: can a trigger-action call stored programs?
A: yes

Q8: Beside before-action and after-action, what other trigger-actions are supported?
A8: for-each-row-action is NOT a third type. Both mysql and oracle let you combine BEFORE and for-each-row

Q: what if a DML where-clause matches no record? Will a before-action run? How about an after-action?

A3: an insert on a table, a delete on a table, or an update OF one or more columns ON a table. In some databases(which?), a call to a stored procedure also qualifies as a trigger event

facade: loose coupling && fewer dependencies

One j4 facade — loose coupling and fewer “dependencies”.

Without a facade, a client object may need 5 instance variables to access 5 “services” either hosted in the same or hosted in a different JVM [2]
– logger “service”
– authentication service
– authorization service
– status-check service
– connection-pool or dataSource
– transaction manager
– sessionFactory’s static “services”
– StudentDAOFactory, ProfessorDAOFactory….

Basic OO principle lets each subject expert author (and maintain) her object, and require all client objects to get a reference [1] (a dependency) to her object.

[1] either static field or instance field
[2] perhaps through JNDI lookup

JVM mem leak detector basics + force GC

Some JVM profilers like JProbe can “force” GC daemon to wake up and run. We know that A regular java method can’t “force” GC daemon thread to wake up and run. But a JVM profiler is not written in java.

jconsole can invoke GC on the target JVM. It’s on the Memory tab, and also in Mbeans -> java.lang->Memory->operations

I think JProbe uses JVM Tool Interface (aka JVM Profiler Interface) to do that? Probably. See The profiler runs in the same process as the JVM,
sharing the address space and have access to all the jvm variables, GC, threads..

Many memory leak detectors work by counting instances for each class and detect growth over time. The assumption — instance count for any class should rise and fall, not rise and rise. IMHO, This is the #1 fundamental assumption in memory leak detectors.

In general, if a system is supposed to generate increasing “live” objects then it will crash sooner or later. However, if under normal load the increase is slow enough relative to the lifespan between VM restarts, then it’s tolerable but still, such a design remains worrisome and questionable for a robust server-side engine.

load factor ]%%lang

When elements exceed 75%[3] of the “existing-buckets”[1] , the hashmap must grow [2]. System doesn’t care if any bucket is shared[4] by multiple elements

Q: What if load factor is too high like 0.99, and we *allow* the hash to become very very full?
A: somehow performance is likely to suffer

Q: what if load factor is set too low, like 0.52?
%%A: I think you get too frequent rehashing(?) and you always have 48% unused memory space(?)

Q: is a bucket similar to a chain in separate-chaining?

[1] current capacity
[2] How it grows is less important now. buzzwords: rehash, double,
[3] default load factor of a “new HashMap()”
[4]due to hash collision.

x++ vs ++x

echo ++$x means “increment first, then evaluate” => returns the modified value
echo $x++ means “evaluate, increment last” => returns the unmodified value

Applies to Java, PHP, Perl and any language.

Many (including experienced) programmers are fuzzy about the difference. It’s best to do

x++; if (x….) instead of if(++x …)