- Cache interceptor: főleg távoli metódushívások elé. Ez talán még nem olyan vészes. Egy akármilyen jcache megteszi neki, vagy egy map is. Újabban adatbázisba perzisztált map-en kisérletezek, annyi adatot kell cachelni és a backend olyan gyenge, hogy a memória + frissítgetés nem lenne jó megoldás.
Ennek még látném valami hasznát egyébként, de azért érdemes odafigyelni a példaértékűen halott spring-modules cache projectjére. - Timeout intercetor: ha a metódus nem tér vissza X idő alatt (lassú backend), akkor hagyja futni és egy bekonfigurált értéket ad vissza helyette, vagy hibát. Ezt nyilván úgy csinálja, hogy külön szálat indít neki.
- re-try interceptor: Szerintem ez a legbetegebb :) Van pár dolog, ami elsőre néha nem sikerül, és ilyenkor simán lehet hogy másodszorra vagy harmadszorra igen. Talán. Szerintem ez botrány, de ez van. Ez az interceptor elkap bizonyos bekonfigurált hibákat és újrapróbálja a hívást. Például egy bankkártya művelet tipikus példa arra, hogy hol nem merném bevetni :-) Persze azok is besz@rnak hébe-hóba.
- Logging interceptor: a lassan válaszoló hívásokat logolja. Nem mintha utánna tudnék javítani a lassú backendeken...
2009. április 3., péntek
Agyhalott AOP svájcibicska
Pár AOP-os cuccom mostanában, ami szerintem egy jól működő rendszerben nem, vagy csak ritkán tudnék elképzelni...