2014年4月23日 星期三

等Braum的Freljord的心,揭示

等Braum的Freljord的心,揭示


該Freljord的冷凍峰數百年來懲罰弱者。但由於這些擔心冰川的土地承載體弱的墳墓,為強大的,土地是一個搖籃,這僅僅是提升強人成為真正​​的冠軍的地方。等Braum的故事開始在這裡,和他的力量和堅韌成長,所以也做了他的傳奇。如今,他的壯舉激勵所有從最貧窮的農民到入侵者的激烈。當他準備承擔他的盾上陣再次,他去知道他攜帶的Freljord的人與他的希望和崇拜。

技能

被動:震盪吹燈

等Braum的基本攻擊申請震盪的打擊。一旦第一個堆棧被應用,從等Braum所有基本的攻擊和他的盟友施加進一步的堆棧。目標是維持4段都驚呆了,並受到魔法傷害。被打暈後,等Braum不能吹燈震盪再次溫和持續時間應用到自己的目標。

問:冬天的咬

等Braum驅使他在一條直線上skillshot盾凍結的冰,造成魔法傷害(基於等Braum的最大生命值),減緩和應用堆棧震盪吹燈的第一目標命中。

W:站在我身後

等Braum躍起到附近盟友的幫助下,他的目標和他們最接近的敵方英雄之間的定位自己,並授予兩個等Braum和他的目標點的護甲和魔法基於他的總護甲和魔法抗性抵抗。

E:堅不可摧

等Braum提高他的盾在目標方向,否定從屏蔽件的方向上的第一次攻擊的破壞和減少的所有後續攻擊的破壞,只要將屏蔽被抬起。等Braum 攔截彈與堅不可摧,使他們打他,然後被銷毀。他還獲得了一個未成年人的速度增加,直到他降低了他的盾牌。

記:冰川裂縫

等Braum抨擊他的盾牌在地上,散發出一股巨大的遠射skillshot的敲起來,破壞前留下一個強烈的緩慢場抓到所有的敵人。

遊戲

等Braum是一個強大而彈性的混戰支持,能夠使改變遊戲規則的劇本,同時節省他的團隊從敵人攻擊的彈幕。他形成了共生的債券,他打架旁邊的神射手,形成兩隊之間的牆,跳躍到他的盟友的幫助下,他轉變成為遊戲後期的坦克。

博特車道

在車道,等Braum功能最有效地為反動或投機取巧的支持,不斷在尋找機會,震盪吹燈向敵人二人。準確使用冬天的撕咬觸發誰已經從他們的走狗波逛到目標的標誌,而等Braum可以跳躍回到了他神射手的遠程安全與站在後面我才標記侵略性的敵人基本攻擊。申請震盪吹燈後,等Braum和他的射手有兩個堅實的選擇:要么跟進難,並嘗試激活眩暈,或區域中的敵人,並採取了積極的定位。震盪吹燈是強大到足以贏得幾乎所有的行業,而引發眩暈的威脅,作為一個強大的威懾力,迫使敵人射手遠離寶貴的奴才黃金。等Braum的過程中友好ganks也是一個強大的資產:按請速他的打野帶支架在我身後,等Braum的抽到了敵人二人的心臟。他們已經被標記為震盪吹燈後,打野的額外攻擊加速的眩暈,並幫助安全殺害。
不過,雖然等Braum是在進攻無可否認有用的,他是一個絕對的巨人防守時。由站在後面我提供的額外防禦都有幫助等Braum和他的神射手生存,否則致命傷害,同時具有堅不可摧所有的傷害時正確定位完全屏蔽他的盟友的潛力。當被激活時,堅不可摧的保護所有的盾牌後面等Braum的盟友從基本的攻擊和針對性和直通狀內翻“穿刺箭,塔里克的炫,和Caitlyn的Piltover睦能力,但不是放在像Nidalee的Bushwhack或斯溫的Nevermove能力。更重要的是,等Braum可以移動,同時使用堅不可摧的,這意味著他可以用他的盟友重新定位,因為他們的頭往自己的塔的安全,或為敵人隊伍移動到左右兩側的防護罩。等Braum還能夠繼續攻擊和鑄造能力,而他用盾牌堅不可摧-登陸緩慢的從冬天的撕咬而搬回阻止敵人junglers和射手更進一步。
等Braum收益固體或引發後續的潛力,一旦他打六級和解鎖冰川裂縫,提供友好的junglers擁有龐大的連鎖和慢容易ganking目標。如果等Braum的希望切斷他的目標的退路,他可以快速地站在我身後射擊冰川裂縫之前,重新定位的背後他的目標。能力的緩慢場大,強大到足以迫使閃爍,安全殺死。最後,冰川裂縫是同樣強大的脫離工具,在正確瞄準廢止追逐。

Teamfights

大約等Braum的更多的盟友,越他的盾牌眼前一亮。在小規模的小規模戰鬥,他一個箭步躥在他的盟友面前與站在後面我用堅不可摧來阻止挑嘗試並享受後續的損害之前。應他的團隊寡不敵眾,冰裂縫又是一個強大的脫離能力,特別是在叢林中的狹窄通道。或者,當更強大的散兵群,一個很好瞄準冬之咬放緩和適用的震盪吹燈,除了保證一殺等Braum的一部分。
而其他支持在敵人隊伍最好的操作在他們的團隊或深,等Braum功能最好的兩支球隊之間的物理牆壁,浸泡了堅不可摧的傷害,而他的球隊的損害經銷商開始工作。在冬天的撕咬低冷卻時間幫助等Braum既緩慢接近並逃離敵人而設立的震盪吹燈他的團隊。他的被動是這裡最強的 - 由兩個隊之間浮動,等Braum的能夠使用敵人的坦克和戰機的基本攻擊,因為他擊中了敵人的防線與冬之咬,可能設立暈眩針對整個敵方隊伍。與此同時,站在我身後給了等Braum突然波速他需要鏢給隊友,保護他們不受傷害與堅不可摧,它有扭轉,即使是最可悲的teamfights,還是保護他的squishies時,他們受到攻擊的可能性。最後,通過敵隊發動分裂冰川裂縫和(字面意思)減慢他們的希望協調的攻擊,給等Braum和他的盟友的機會,在移動和清理。

協同效應

用效果很好:

鬥爭反對:

  • 阿什

    通過減緩她的敵人,阿什給等Braum他冬天的撕咬蒙上了更容易的目標。同樣,兩個可配對冰川裂縫和魔法水晶箭一起完全癱瘓敵人和所有,但保證六級殺。

  • Zyra

    Zyra擁有一個工具包,輕而易舉地繞過等Braum的防禦。通過種植他身後的種子,她能否定堅不可摧的致命布盧姆。抓根也圈套等Braum,防止他保護他的神射手與站在後面我。

  • Caitlyn

    隨著她的無與倫比的範圍,Caitlyn最好的把握等Braum的被動,震盪的打擊。用聰明的時機,等Braum也可以使用站在後面我為Caitlyn火災90口徑淨,必要時幫助兩國逃生和潛水。


  • Vayne

    Vayne的得到了一些技巧了她的袖子斷言她的支配權等Braum。翻滾的低冷卻時間讓她躲閃冬之咬相對容易,而譴責投擲等Braum回來,即使他的屏蔽與堅不可摧,讓Vayne進入她的敵人神射手。

  • Ezreal

    Ezreal的秘術射擊適用於重災區的影響,這意味著一旦等Braum的應用震盪吹燈,Ezreal可以從距離進一步增加棧與他問:這樣做的純粹的威脅就足以迫使大多數的敵人遠離養殖。

  • 俊秀

    露露能出位置堅不可摧通過鑄造幫助,pix的!對等Braum或他的射擊關閉Glitterlance傷害並減緩前兩個射手。






冠軍見解

等Braum,由RiotWrekz設計
如同所有的冠軍,我們設計等Braum填寫傳奇冠軍池聯盟的特定差距。具體地講,他是第一個真正的坦克支援,我們已經創建了,誰需要命中為自己的球隊一個冠軍。我們已經有足夠的防禦支架-像娜美,索拉卡,珍娜等冠軍-誰否定通過治愈或盾牌的傷害,隨著戰鬥機的支持像利昂娜和阿利斯塔爾,誰是一般偉大的開始teamfights潛水前深入敵隊和干擾盡可能。等Braum的不同的東西:他是一個坦克遊戲支持誰是變相的命中為他的球隊,因此需要新的思維方式,位置和遊戲風格,以最傳統的支持。
關鍵等Braum的獨特的遊戲風格是堅不可摧的,他的E。這是一個積極的防禦,類似於康夫的風牆,但同時康夫的能力的創建,使他不得不保護自己的手段(團隊工具被認為是一種次要的獎金) ,我們專門設計堅不可摧,這樣等Braum可以保護他的團隊。它使等Braum不同,因為他-比其他任何冠軍-創建安全區在他身後。在整個比賽中,首先由拉寧在保護他的神射手,然後通過保護他的整個團隊和後期遊戲中坦克。而其他支持,專注於拋光,癒合或中斷,等Braum填補了兩隊之間的獨特作用,同時為自己的球隊的損害首當其衝,讓他損害經銷商做自己的事情。
這個職位他從字面上兩隊之間,並且給了我們一些有趣的設計問題來回答。具體來說,是怎麼回事就在戰鬥防禦近身的支持貢獻時,他有傷害有限,只能降落在敵人的前線仡基本攻擊?這是我們帶來了他的被動,震盪吹燈,和Q,冬之咬。等Braum可以騷擾,同時保護,不一定要通過自己的力量,而是通過應用震盪吹燈到敵方目標。這極大地放大他的球隊的同時保持等Braum的定位貫穿始終teamfights力量。雖然等Braum不能輕易騷擾敵人的防線(冬之咬只影響它擊中第一個敵人,和等Braum的基本攻擊是近戰),當他的盟友得到被敵方戰機和坦克跳了起來,他可以快速地站在後面我才重新定位脫皮與震盪吹燈多個目標。
我們很高興地看到你們做等Braum的。如果你有興趣在試探他演活了發布之前,進入筆試模式,並給他一掄。我們很想得到您的反饋!

2014年4月17日 星期四

Setting Bean Properties and Initializing Beans

Setting Bean Properties
Bean properties are set using the setProperty element. This element requires a bean
name (from the ID in the useBean element), a property, and a value attribute, as shown
in the following:
<jsp:setProperty name=”<bean name>”
➥ property=”<property name>” value=”<expression>”/>
To set the name of the example NameBean to winston, you would use the following:
<jsp:setProperty name=”myBean” property=”name” value=”winston”/>
As with getProperty, the bean method can be called explicitly from a Java scriptlet:
<% myBean.setName(“winston”); %>

A useful feature of the setProperty tag is that bean properties can also be initialized
from the HTTP request parameters. This is accomplished by using a param attribute
rather than the value attribute:
<jsp:setProperty name=”<bean name>” property=”<property name>” param=”<name>”/>
The value of the named parameter is used to set the appropriate bean property. To use a
request parameter called name to set the NameBean property of the same name, you could
use the following:

<jsp:setProperty name=”myBean” property=”name” param=”name”/>

In fact, the param attribute can be omitted if the property name is the same as the request
parameter name. So the previous example could have put more succinctly as follows:
<jsp:setProperty name=”myBean” property=”name”/>
A last form of the setProperty bean is employed when multiple parameters are used to
initialize several bean properties. If the property name is set to *, all of the form request
parameters are used to initialize bean properties with the same name:
<jsp:setProperty name=”myBean” property=”*”/>

Initializing Beans 

Some beans require properties to be defined to initialize the bean. There is no mecha-
nism for passing in initial values for properties in the jsp:useBean element, so a syntac-
tic convention is used instead.

Conventionally, if a bean must have properties defined before it can be used on the Web
page, the jsp:useBean is defined with an element body and the jsp:setProperty tags
are defined in the useBean body to initialize the required properties.

For example, assuming that the simple NameBean example requires the name to be initial-
ized, the following useBean syntax would be used:
<jsp:useBean id=”myBean” class=”NameBean” scope=”request” >
<jsp:setProperty name=”myBean” property=”name” value=”winston”/>
</jsp:useBean>


In fact, the param attribute can be omitted if the property name is the same as the request
parameter name. So the previous example could have put more succinctly as follows:
<jsp:setProperty name=”myBean” property=”name”/>
A last form of the setProperty bean is employed when multiple parameters are used to
initialize several bean properties. If the property name is set to *, all of the form request
parameters are used to initialize bean properties with the same name:
<jsp:setProperty name=”myBean” property=”*”/>
The bean must define a property for every parameter in the HTTP request;
otherwise, an error occurs.

Initializing Beans 
Some beans require properties to be defined to initialize the bean. There is no mecha-
nism for passing in initial values for properties in the jsp:useBean element, so a syntac-
tic convention is used instead.

Conventionally, if a bean must have properties defined before it can be used on the Web
page, the jsp:useBean is defined with an element body and the jsp:setProperty tags
are defined in the useBean body to initialize the required properties.
For example, assuming that the simple NameBean example requires the name to be initial-
ized, the following useBean syntax would be used:
<jsp:useBean id=”myBean” class=”NameBean” scope=”request” >
<jsp:setProperty name=”myBean” property=”name” value=”winston”/>
</jsp:useBean>

Using a Bean with the Agency Case Study

The next example uses the Agency case study code and refactors the name.jsp Web page
shown in Listing 13.6 to use a JavaBean. This time, you will use a bean to hide the com-
plex JNDI lookup and type casting needed to access the agency Session EJB.
The new JSP page is shown in Listing 13.9.


1: <HTML>
2: <TITLE>Agency Name</TITLE>
3: <BODY>4: <jsp:useBean id=”agency” class=”web.AgencyBean” scope=”request” />
5: <H1><jsp:getProperty name=”agency” property=”agencyName”/></H1>
6: </BODY>
7: </HTML>
This is much simpler for a non-Java developer to work with. All of the code required to
create the EJB using its JNDI name has been spirited away into a JavaBean of class
web.AgencyBean. This bean does not have any properties but simply defines a large num-
ber of business methods whose only purpose is to delegate behavior to the underlying
agency Session bean.


LISTING 13.10 Full Text of web.AgencyBean.java
1: package web;
2:
3: import java.rmi.*;
4: import java.util.* ;
5: import javax.ejb.* ;
6: import javax.naming.* ;
7:
8: import agency.*;
9:
10: public class AgencyBean
11: {
12:     Agency agency;
13:
14:     public AgencyBean ()
➥ throws NamingException, RemoteException, CreateException {
15:         InitialContext ic = null;
16:         ic = new InitialContext();
17:         AgencyHome agencyHome =
➥ (AgencyHome)ic.lookup(“java:comp/env/ejb/Agency”);
18:         agency = agencyHome.create();
19:     }
20:
21:     public String getAgencyName() throws RemoteException {
22:         return agency.getAgencyName();
23:     }
24:
25:     public Collection findAllApplicants() throws RemoteException {
26:         return agency.findAllApplicants();
27:     }
28:    

2014年4月16日 星期三

JSP Syntax and Structure

JSP Syntax and Structure
Before writing your first JSP, you need to gain an understanding of the syntax and the
structure of a JSP.As you have seen, JSP elements are embedded in static HTML. Like HTML, all JSP ele-
ments are enclosed in open and close angle brackets (< >). Unlike HTML, but like XML,
all JSP elements are case sensitive.

JSP elements are distinguished from HTML tags by beginning with either <% or <jsp:.
JSPs follow XML syntax, they all have a start tag (which includes the element name) and
a matching end tag. Like XML tags, a JSP tag with an empty body can combine the start
and end tags into a single tag. The following is an empty body tag:
<jsp:useBean id=”agency” class=”web.AgencyBean”>
</jsp:useBean>

The following tag is equivalent to the previous example:
<jsp:useBean id=”agency” class=”web.AgencyBean”/>
Optionally, a JSP element may have attributes and a body. You will see examples of all
these types during today’s lesson. See Appendix C, “An Overview of XML,” for more
information on XML and the syntax of XML elements.

JSP Elements
The basic JSP elements are summarised in Table 13.1.
TABLE 13.1 JSP Elements
Element Type JSP Syntax Description
Directives <%@Directive…%> Information used to control the translation of the
JSP text into Java code
Scripting <%    %> Embedded Java code
Actions <jsp:   > JSP-specific tags primarily used to support
JavaBeans
You will learn about scripting elements first and then cover directives and actions later in
today’s lesson.
Scripting Elements
Scripting elements contain the code logic. It is these elements that get translated into a
Java class and compiled. There are three types of scripting elements—declarations,
scriptlets, and expressions. They all start with <% and end with %>.

Declarations
Declarations are used to introduce one or more variable or method declarations, each one
separated by semicolons. A variable must be declared before it is used on a JSP page.
Declarations are differentiated from other scripting elements with a <%! start tag. An
example declaration that defines two variables is as follows:
<%! String color = “blue”; int i = 42; %>

You can have as many declarations as you need. Variables and methods defined in decla-
rations are declared as instance variables outside of any methods in the class.
Expressions
JSP expressions are single statements that are evaluated, and the result is cast into a
string and placed on the HTML page. An expression is introduced with <%= and must
not be terminated with a semi-colon. The following is an expression that will put the
contents of the i element in the items array on the output page.
<%= items[i] %>

JSP expressions can be used as values for attributes in JSP tags. The following example
shows how the i element in the items array can be used as the value for a submit button
on a form:
<INPUT type=submit value=”<%= items[i] %>”>

What is a JSP?

JavaServer Pages

Yesterday, you looked at developing Web applications using Java servlets.
Servlets have the advantage of being able to generate the HTML Web page
dynamically. The disadvantage of servlets is the fact that the developer must
generate a lot of HTML formatting information from within Java. Servlets can
be described as large amounts of boring HTML println() statements inter-
spersed with small amounts of interesting Java code.
Servlets make it difficult to differentiate the presentation layer from the logic
layer of an application. This duality of purpose means that servlets do not allow
the roles of HTML designer and Java programmer to be easily separated.
Writing servlets requires the members of the development team to be either
• Java programmers who must learn HTML and Web design
• Web designers who must learn Java

In practice, there are very few Java programmers who make good Web design-
ers, and fewer Web designers who make good Java programmers.
JavaServer Pages are servlets that are written in HTML. Actually, there is a bit
more to it than that, but the Java code on a JSP is usually either non-existent or
very simple, and can be readily understood by non-Java programmers.In today’s lesson, you will learn
• What a JSP is and how its implementation differs from servlets
• The JSP lifecycle—what you have to do and what the Web server will do for you
• How to deploy a JSP
• How to use JavaBeans to hide Java functionality from the JSP
• How to develop a Web application using JSPs
Today’s work builds directly on the knowledge gained yesterday because many of the
mechanisms used in JSPs are the same as servlets.

What is a JSP?
A JSP is just another servlet, and like HTTP servlets, a JSP is a server-side Web compo-
nent that can be used to generate dynamic Web pages.
The fundamental difference between servlets and JSPs is
• Servlets generate HTML from Java code.
• JSPs embed Java code in static HTML.
To illustrate this difference, Listings 13.1 and 13.2 are the same Web page coded as a
servlet and as a JSP, respectively. Each Web page simply reads a parameter called name
from the HTTP request and creates an HTML page displaying the value of the name
parameter. Listing 13.1 shows the servlet, and Listing 13.2 shows the JSP.

LISTING 13.1 Simple Dynamic Page As a Servlet

1: import java.io.*;
2: import javax.servlet.*;
3: import javax.servlet.http.*;
4:
5: public class Hello extends HttpServlet {
6:
7:     public void doGet(HttpServletRequest req, HttpServletResponse res)
8:                  throws ServletException, IOException {
9:         res.setContentType (“text/html”);              
10:         PrintWriter out = res.getWriter();              
11:         String name = req.getParameter(“name”);
12:         out.println (“<HTML>”);
13:         out.println (“<HEAD><TITLE>Hello</TITLE></HEAD>”);
14:         out.println (“<BODY>”);
15:         out.println (“<H1>Hello “ + name + “</H1>”);
16:         out.println (“</BODY>”);
17:         out.println (“</HTML>”);
18:     }
19: }


1: <HTML>
2:   <HEAD><TITLE>Hello</TITLE></HEAD>
3:   <BODY>
4:     <% String name = request.getParameter(“name”); %>
5:     <H1>Hello <%=name%> </H1>
6:   </BODY>
7: </HTML>

Here you can see that the JSP not only requires far less typing, but a lot of the work is
being done for you. How the JSP achieves the same effect with far less code will soon
become clear.
Separating Roles
With a servlet, the Java programmer was forced to generate the entire HTML. With a
JSP, it is much easier to separate the HTML from the application tasks. With the use of
JavaBeans and JSP tag libraries (covered on Day 14, “JSP Tag Libraries”), this separa-
tion is even more explicit.

Using JSPs, the Web designer can concentrate on the design and development of the
HTML page. When a dynamic element is needed, the developer can use a pre-written
bean or tag library to provide the data. The Java programmer can concentrate on develop-
ing a useful set of beans and tag libraries encapsulating the complex Java required to
retrieve the data from an EJB, a database, or any other data source.
Translation and Execution

JSPs differ from servlets in one other respect. Before execution, a JSP must be converted
into a Java servlet. This done in two stages:
1. The JSP text is translated into Java code.
2. The Java code is compiled into a servlet.
The resulting servlet processes HTTP requests. The translate and compile process is per-
formed once before the first HTTP request can be processed. The JSP lifecycle is cov-
ered in more detail later.

2014年4月14日 星期一

Bean Managed Transaction Demarcation

If an EJB is deployed using bean managed transaction demarcation (here referred to as
BMTD, though this abbreviation isn’t used in the EJB specification itself), the EJB con-
tainer allows the bean to obtain a reference to a javax.transaction.UserTransaction
object using the EJBContext. You can see this in Figure 8.3.

Motivation and Restrictions

An EJB might need to be deployed under BMTD if the conditions on which a transaction
is started depend on some programmatic condition. It could be that one method starts the
transaction and another method completes the transaction.
However, the cases where BMTD is needed are few and far between. Indeed, they are so
rare that the EJB specification limits BMTD to Session beans. Entity beans can only be
deployed with CMTD. This makes sense because Entity beans represent persistent trans-
actional data; the transaction context should be as deterministic as possible.
Moreover, if a stateless Session bean starts a transaction, it must also commit that trans-
action before the method completes. After all, the stateless Session bean will have no
memory of the client that just invoked its method after that method completes, so one
cannot expect that the transaction context is somehow miraculously preserved. If you
write a BMTD stateless Session bean that does not commit its own transaction, the EJB
container will rollback the transaction and throw an exception back to the client
(java.rmi.RemoteException for remote clients, or javax.ejb.EJBException for local).
Indeed, even with stateful Session beans, there is a restriction. Any current transaction in
progress when the BMTD Session bean is called will be suspended by the EJB container,
not propagated to the BMTD bean. It is possible that, from the bean’s perspective, there
is a current transaction, but that would refer to any transaction not committed when a
method on that bean was last called.

Using the Java Transaction API
When a Session bean is deployed under BMTD, there is an implementation choice as to
how it should manage its transactions. If interacting solely with an RDBMS, the Session
bean can manage the transactions directly through the JDBC API. Alternatively, it can
use the Java Transaction API, defined by the classes and interfaces in the javax.trans-
action and the javax.transaction.xa packages. The latter is to be preferred, if only
because transactional access to Java Messaging Service resources (you’ll be learning
more about these tomorrow and the day after) can only be performed through the JTA
API. Equally, servlets can also use the JTA API.

For a Session bean to start a transaction, it should first call the getUserTransaction()
method of its SessionContext. You’ll recall that this was the method that throws an
exception under CMTD, but it is the centerpiece of transaction control under BMTD.
Obtaining a UserTransaction does not mean that a transaction has been started. Rather,
it must be started using the begin() method. The transaction can then be completed
using either the commit() or the rollback() method. The current status can also be
obtained using getStatus(). This returns an int whose meaning is defined by the
constants in the javax.transaction.Status interface. Some of the most common status
values are shown in Table 8.2.

JAVA : Transactions and Persistence

Overview of Transactions

If you’ve used RDBMS before, or completed a Computer Studies course or read any
other J2EE book, you’ve probably read a section like this one already. But read on any-
way, if only to be acquainted with some of the J2EE terminology that is used in this
arena.
A transaction is an atomic unit of work:

• Atomic unit means indivisible—either every step within the transaction completes
or none of them do.

• Work here usually means some modification to data within a persistent data store.
In RDBMS terms, this means one or more INSERT, UPDATE, or DELETEs. However,
strictly speaking, it also applies to reading of data through SELECT statements.
For a persistent data store to support transactions, it must pass the so-called “ACID” test:
• Atomic—The transaction is indivisible; the data store must ensure this is true.

• Consistent—The data store goes from one consistent point to another. Before the
transaction, the data store is consistent; afterwards, it is still consistent.
The age-old example is of transferring money between bank accounts. This will
involve two UPDATEs, one decrementing the balance of account #1 and the other
incrementing the balance of account #2. If only one UPDATE occurs, the transaction
is not atomic, and the data store is no longer in a consistent state.

• Isolation—The data store gives the illusion that the transaction is being performed
in isolation. Enterprise applications have many concurrent users who are all per-
forming transactions at the same time, so behind the scenes, the data store uses tech-
niques, such as locks, to serialize access to the contended data where necessary.

• Durability—If a transaction completes, any changes made to the data as a result of
that transaction must be durable. In other words, if the power were to fail a mil-
lisecond after the transaction has completed, the change must still be there when
power is reconnected.


Many data stores use transaction logs to address this requirement. The transaction
log holds a journal of changes made to the actual data. When the transaction com-
pletes, the log is written to disk, although the actual data need not be.

Many data stores allow transactions to be started explicitly using a syntax such as the
following:
begin transaction t1
where t1 is the (optional) name transaction. Transactions are completed using either
commit (make changes permanent) or rollback (undo all changes made in the transac-
tion, and revert all data back to the state before the transaction began). Many data stores
will use
commit transaction t1
and
rollback transaction t1


In the EJB specification, these two responsibilities are split. In principle, you can think
of the EJB container as acting as the transaction manager, and the persistent data store
acting only as the resource manager. The term transaction coordinator is sometimes used
instead of transaction manager because there could be more than one resource whose
transactions are being coordinated.

Splitting the responsibilities of transaction management and resource management has
two consequences. For the bean provider, it means that to start a transaction, the bean
must interact both with the EJB container and with the persistent data store. The former
interaction is largely implicit because it is configured through the deployment descriptor
(and as you know, the latter interaction is implicit if CMP Entity beans are used). The
other consequence is that, for the persistent data store, it must defer all transaction con-
trol responsibility up to the EJB container. Behind the scenes, there is some quite sophis-
ticated communication going on; you’ll learn a little about this activity later on today.

2014年4月13日 星期日

馬航副機師疑打手機求救

在馬航MH370客機失蹤五個星期仍然下落不明之際,馬來西亞國營《新海峽時報》周六表示調查有新發現,指客機三月八日凌晨從雷達屏幕消失後,副機師法里克趁着客機在檳城附近上空低空飛行時,曾在機上嘗試用手機撥打電話,惟電話通訊突然中斷,可能是因為客機當時以高速遠離地面通訊塔。
  報道引述消息人士稱,MH370失聯後曾經低空飛行,當時它在大馬西岸檳城附近上空的低空飛行高度,足以讓最近的地面通訊塔接收到機上手機訊號。調查人員正在深入調查這一項新發現,冀能完整呈現MH370從雷達消失前一刻,機上發生過的事情。MH370最後從軍方雷達屏幕消失時,位置在檳城西北約三百二十公里。專家表示,通訊塔可接收到從七千呎高度傳來的手機訊號。
  對於法里克的電話通訊突然中斷,消息人士認為原因可能是MH370急速飛離接收到機上手機訊號的通訊塔後,沒有飛入另一處通訊塔所在的訊號覆蓋區。在這篇題為「絕望的求救電話」的頭版報道中,沒提到法里克要打給誰,因為消息人士不肯泄露調查細節。
  不過,《新海峽時報》也引述另一批接近調查的消息人士稱,法里克的手機在MH370起飛前已中斷連綫,在飛機偏離航道轉變方向至消失之間的一段時間內,法里克的手機又重新駁綫,但無法肯定他是否真的有打出電話。所謂「重新駁綫」,未必一定顯示有人打出電話,可能只是飛機上有人再次開啟手機,而地面通訊塔接收到有關手機訊號。
  當局也追查法里克的電話記錄,顯示他最後通話的人是他平日經常聯絡的,那個人的電話號碼在他的撥電記錄中頻繁出現。法里克的一名親戚上周一表示,法里克與母親之間的關係密切,如果他在飛機消失前真的打過電話,可能是聯絡她。
  《新海峽時報》也表示,法里克最後一次以智能手機軟件WhatsApp Messenger通訊,是三月七日深夜十一時半,即MH370起飛之前一小時多,當晚MH370於三月八日零時四十一分從吉隆坡國際機場起飛。
  大馬代理交通部長希山慕丁回應該篇報道表示:「除非我們經過查證,否則無法談論這些報道。」他說:「如果真有其事,我們應早就知道了。」
  調查人員於上月指MH370飛出馬來西亞領空時,不但蓄意改變航道,並以人手關閉機上通訊系統,令警方馬上展開刑事調查。MH370為何失聯仍是一個謎,多方作出的推測「各說各話」,有推測指是劫機或恐襲,甚至有人認為是機師蓄意墜機自殺。