AWS 紀錄

繼上週為了在AWS上跑K8S，就開始踏上雲端服務之旅，在註冊完後(IAM)就會開始進到AWS管理控制台，也買了自己在AWS的網域服務(Route 53)，啟用了S3 儲存貯體來放置k8s的相關設定。
本週(2020-02-22)進修ELK時，網路上看到有人分享怎麼用EC2，所以也跟著試著創立一個Ubuntu的instance，創建過程中會讓我們下載*.pem檔，透過puttyGen從pem檔產生*ppk，在載入此ppk檔後就可以在Windows由putty連上該台server，完全不用輸入帳號與密碼即可login。

Something about HTTP

錨點(Anchor) : 在URL的結尾附近會看到井字號(#)，這個功能目的是為了讓瀏覽者能從跳到另一頁時回到原本的頁面處，或是做為同一頁面的位置快速導向。

HTTP的表頭(header)中referer 主要用來讓伺服器來判斷使用者是從哪個頁面來的，比如從搜尋網站或是其他合作網站連結過來的，其他用途可做為判斷網站內的圖檔如果不是同網域內來的就不能看到此圖片，不過因為這個referer容易被偽造後續被拿來應用的機會就很少了。

關於瀏覽器的快取(cache)，request的header 會使用Pragma:no-cache 和 Cache-Control : no-cache 目的是一樣的，主要是前者為HTPP 1.0中定義而為了相容才會這兩個同時使用。
而這個快取的機制就曾經在工作上遇到問題，因為IE很討厭的就算設定"從不"使用快取有時也沒有用，所以只好在每個request(包含各個宣告引用javascript檔案)串上當下時間字串，讓瀏覽器不去用快取而去server取新檔案。因為在js某個版本有修改，但使用者端因為快取沒去下載會導致網站發生異常等error事件，所以強迫串上會變動的URL。如: abj.js ? ts=84736138
後面的ts參數所帶的值就會在每次進到該頁面時都不一樣，這樣就不會有快取的情況。

2019中華職棒總冠軍心得

這次的總冠軍很有話題性，適逢恰恰的球員生涯結束和Lamigo的三年霸夢想與轉賣，當然這是眾所皆知的話題，比賽結果雖然失望但對我這種看過大風大浪的棒球迷來說沒什麼好感傷反而是因為兩位寶貝女兒(九歲及六歲)第一次看總冠軍賽，樂趣在於和家人一起熱忠於看棒球的過程。

來說說這次總冠軍的心得，第一場在恰恰九上打回追平的兩分打點二壘安打，全家high翻天了，鄰居一定覺得是怎樣...，不過最後Lamigo的再見安讓今天的激情很快地平靜了
第二場，Lamigo投手在一局爆炸的情況而兄弟廖乙忠穩定表現，最終來到系列賽1:1局面。

等待星期一的休兵日，一直在期待星期二的比賽快點到來，當時的認為是兄弟的主場三連戰很有機會直接三連勝就封王，但是...棒球就是那麼神奇與無法預知，老話一句:球是圓的。
沒想到這三戰的結果卻是因為投手的崩盤直接三連敗，直接系列賽4:1 Lamigo在兄弟主場的台中洲際封王，後續的檢討新聞一堆就不想說了。

今天2019-10-20 早上8:50，棒球比賽還有晚上的亞錦賽冠軍戰(中華對日本)，最期待的還是11月初的12強，所以呢，今年的棒球生活樂趣還沒有結束ㄟ，就繼續享受看下去吧!

台灣棒球加油! 中華隊加油 ! 中華職棒加油 !

Java 生態的命名變化

2019-07-04 Java EE 由Eclipse基金會 re-branding 為 Jakarta EE

2006-05 J2EE 被捨棄而成為Java EE，而數字2 對於非企業版的J2SE 也拿掉後，
改為 Java SE 5 (2004)

• Jakarta EE 意指 version 9 (2019)含以上將使用 jakarta namespace.
• Java EE 意指 Java EE 5 (2006) 至 Java EE 8 (2017), 使用 javax namespace.
• J2EE 意指 Java EE 4 含以下, 使用 javax namespace.

交易控制與lock實例

今天先將最近遇到第二次交易無法完成的現象寫下，後續再把完整的交易控制觀念補上。

這次是遇到三個系統界接所造成的lock情境:

(使用spring的交易控制)
A=>C=>B
A 系統為觸發的主角、B和C為A系統某個交易控制中各自的一個作業或服務(service)

此交易為A開始後，先呼叫C系統的一個作業，由於C系統的commit動作一律不處理，也就是須由呼叫者A決定是否成立，而B作業是在A呼叫C後的同一個交易控制中的一個作業，這就是說明B和C是綁定在同一個交易控制中，但因為C會因需要更新某個table的資料導致該筆資料是被lock情況(須等解lock )而B作業也會去看該筆資料，造成B需等待C解lock 後才可取到值，可是這是在同一個交易管理中，A因為要等到B完成後才可以commit (解開C的lock)又遲遲等不到，導致畫面就卡住直到A的連線timeout發生錯誤後發生rollback才結束。

等待循環: C等A下commit，B等C解lock，A又等B回應。三方互等就是挨餓狀況!

這種案例是因為三個系統都是不同單位的人負責，大家都不知道彼此做了哪些事，最後要不斷嘗試找到問題點，最終雖將B抽離開本交易流程即可解決，但大公司的系統往往就是會遇到這種罕見的案例。若是很單純ABC都由同一單位的人開發應該就會很清楚這種同一table中資料有修改到就是會發生這種lock。當然也可以怪開發的人隨便把B決定放在此交易中，不過大家也知道這種事難免因為新人或不注意會被引起，解問題就是一門學問和經驗了 !

Mybatis dynamic sql

這次專案是對既有的DB資料來開發系統，用到 Mybatis的generator 和dynamic sql 產生mapper及sql語法(不用寫任何的xml及欄位對應)  其中selectByExample 是對所有欄位都取出，但條件是依照web UI所輸入的欄位動態產生where condition，isEqualToWhenPresent就是當參數非null才會產生該條件，另外一個需求是需透過程式的if condition來動態加上條件。這些寫法也是透過官網的範例逐一摸索出來的，給有需要的人參考看看。

import static org.mybatis.dynamic.sql.SqlBuilder.isEqualToWhenPresent;
import static org.mybatis.dynamic.sql.SqlBuilder.isIn;
import static org.mybatis.dynamic.sql.SqlBuilder.isNull;
import org.mybatis.dynamic.sql.select.MyBatis3SelectModelAdapter;
import org.mybatis.dynamic.sql.select.QueryExpressionDSL;
...

@Override
 public Optional> searchEmployees(EmployeeCondition byCondition) {
                 QueryExpressionDSL>>.QueryExpressionWhereBuilder dsl =mapper.selectByExample()
               .where(BpsnDynamicSqlSupport.bpeno, isEqualToWhenPresent(byCondition.getBpeno()))
               .and(BpsnDynamicSqlSupport.alias, isEqualToWhenPresent(byCondition.getAlias()))
               .and(BpsnDynamicSqlSupport.bpnme, isEqualToWhenPresent(byCondition.getBpnme()))
               .and(BpsnDynamicSqlSupport.mobile1, isEqualToWhenPresent(byCondition.getMobile1()))
               .and(BpsnDynamicSqlSupport.address, isEqualToWhenPresent(byCondition.getAddress()))
               .and(BpsnDynamicSqlSupport.passportno, isEqualToWhenPresent(byCondition.getPassportno()));
   
    if(EmployeeQuery.ACTIVE.equals(EmployeeQuery.valueOf(byCondition.getWorkType()))) {
     dsl.and(BpsnDynamicSqlSupport.bpedy, isNull());
   }else if(EmployeeQuery.TRANSFER.equals(EmployeeQuery.valueOf(byCondition.getWorkType()))) {
    dsl.and(BpsnDynamicSqlSupport.deptNo, isIn("L","M"));
   }
   
         List list  =  dsl.build().execute();
         return list==null ? Optional.empty() : Optional.of(list);
 }
 

Annotation for transaction management on Spring

使用annotation的優點是明確表示這個方法的交易管理，立即與開發者做出約束
在交易的方法內要盡快地完成，不要穿插一些RPC或HTTP等請求以避免延誤到結束時間，
並非每個方法都要宣告交易，如果只有一個修改指令或只有讀取的指令就不需要使用到交易控制。