Dropbox 上手指南

Dropbox注冊非常簡單，點(diǎn)擊注冊:

簡單填寫之后可以擁有了免費(fèi)的2G的空間了。在Dropbox的web界面可以直接上傳文件了，但是如果緊緊提供這些功能那么Dropbox也就是緊緊只是一個(gè)普通的云存儲(chǔ)了，真正貼心的功能在于它的客戶端。廢話少說，注冊之后有用戶指南會(huì)引引導(dǎo)你到下載客戶端頁面。一步步安裝之后就可以指定某個(gè)文件夾同步到云端了。

Dropbox有哪些特色

1. 免費(fèi)的2G空間（目前官方的活動(dòng)可以將免費(fèi)空間擴(kuò)展到5.25G）
2. 速度不錯(cuò)（公司電信和家杭州網(wǎng)通都可以達(dá)到220K下行和26K的上行速度）
3. 貼心的客戶端，你只要將文件拖進(jìn)文件夾，客戶端就會(huì)自動(dòng)同步。
4. 支持linux，mac，Windows 甚至iphone
5. 免費(fèi)的外鏈和多人共享空間

Dropbox有哪些不足之處

1. 沒辦法同步多個(gè)文件夾（可以通過junction命令將文件夾硬連到同步目錄去）
2. 客戶端同步計(jì)劃不可編輯，它會(huì)在每臺(tái)機(jī)器上都會(huì)同步所有的文件，文件大了就麻煩了。

可以改進(jìn)之處（個(gè)人愚見）

1. 加強(qiáng)客戶端功能，允許用戶制定同步計(jì)劃，在線規(guī)劃后哪些文件需要同步到哪些機(jī)器，哪些文件無需同步到所有機(jī)器等。
2. 支持多文件夾，以及網(wǎng)絡(luò)映射
3. 支持同步策略制定，比如只上傳不下載、只下載不上傳等策略。

相關(guān)鏈接

• Dropbox主頁

2009 年 7 月 31 日

事務(wù)策略系列文章的作者 Mark Richards 將討論如何在 Java? 平臺(tái)中為具有高吞吐量和高用戶并發(fā)性需求的應(yīng)用程序?qū)崿F(xiàn)事務(wù)策略。理解如何進(jìn)行折衷將幫助您確保高水平的數(shù)據(jù)完整性和一致性，并減少隨后開發(fā)流程中的重構(gòu)工作。

我在本系列 的前幾篇文章中所介紹的 API 層和客戶端編排策略事務(wù)策略是應(yīng)用于大多數(shù)標(biāo)準(zhǔn)業(yè)務(wù)應(yīng)用程序的核心策略。它們簡單、可靠、相對易于實(shí)現(xiàn)，并且提供了最高水平的數(shù)據(jù)完整性和一致性。但有時(shí)，您可能需要減小事務(wù)的作用域以獲取吞吐量、改善性能并提高數(shù)據(jù)庫的并發(fā)性。您如何才能實(shí)現(xiàn)這些目的，同時(shí)仍然維持高水平的數(shù)據(jù)完整性和一致性呢？答案是使用 High Concurrency 事務(wù)策略。

High Concurrency 策略源自 API 層 策略。API 層策略雖然非常堅(jiān)固和可靠，但它存在一些缺點(diǎn)。始終在調(diào)用棧的最高層（API 層）啟動(dòng)事務(wù)有時(shí)會(huì)效率低下，特別是對于具有高用戶吞吐量和高數(shù)據(jù)庫并發(fā)性需求的應(yīng)用程序。限制特定的業(yè)務(wù)需求，長時(shí)間占用事務(wù)和長時(shí)間鎖定都會(huì)消耗過多資源。

與 API 層策略類似，High Concurrency 策略釋放了客戶機(jī)層的任何事務(wù)責(zé)任。但是，這還意味著，您只能通過客戶機(jī)層調(diào)用一次任何特定的邏輯工作單元（LUW）。High Concurrency 策略旨在減小事務(wù)的總體作用域，以便資源鎖定的時(shí)間更短，從而增加應(yīng)用程序的吞吐量、并發(fā)性以及性能。

通過使用此策略所獲取的好處在一定程度上將由您所使用的數(shù)據(jù)庫以及它所采用的配置決定。一些數(shù)據(jù)庫（比如說使用 InnoDB 引擎的 Oracle 和 MySQL）不會(huì)保留讀取鎖，而其他數(shù)據(jù)庫（比如沒有 Snapshot Isolation Level 的 SQL Server）則與之相反。保留的鎖越多，無論它們是共享還是專用的，它們對數(shù)據(jù)庫（以及應(yīng)用程序）的并發(fā)性、性能和吞吐量的影響就越大。

但是，獲取并在數(shù)據(jù)庫中保留鎖僅僅是高并發(fā)性任務(wù)的一個(gè)部分。并發(fā)性和吞吐量還與您釋放鎖的時(shí)間有關(guān)。無論您使用何種數(shù)據(jù)庫，不必要地長時(shí)間占用事務(wù)將更長地保留共享和專用鎖。在高并發(fā)性下，這可能會(huì)造成數(shù)據(jù)庫將鎖級(jí)別從低級(jí)鎖提高到頁面級(jí)鎖，并且在一些極端情況下，從頁面級(jí)鎖切換到表級(jí)鎖。在多數(shù)情況下，您無法控制數(shù)據(jù)引擎用于選擇何時(shí)升級(jí)鎖級(jí)別的啟發(fā)方法。一些數(shù)據(jù)庫（比如 SQL Server）允許您禁用頁面級(jí)鎖，以期它不會(huì)從行級(jí)鎖切換到表級(jí)鎖。有時(shí)，這種賭博有用，但大多數(shù)情況下，您都不會(huì)實(shí)現(xiàn)預(yù)期中的并發(fā)性改善。

底線是，在高數(shù)據(jù)庫并發(fā)性的場景中，數(shù)據(jù)庫鎖定（共享或?qū)Ｓ茫┑臅r(shí)間越長，則越有可能出現(xiàn)以下問題：

• 數(shù)據(jù)庫連接耗盡，從而造成應(yīng)用程序處于等待狀態(tài)
• 由共享和專用鎖造成的死鎖，從而造成性能較差以及事務(wù)失敗
• 從頁面級(jí)鎖升級(jí)到表級(jí)鎖

換句話說，應(yīng)用程序在數(shù)據(jù)庫中所處的時(shí)間越長，應(yīng)用程序能處理的并發(fā)性就越低。我所列出的任何問題都會(huì)造成您的應(yīng)用程序運(yùn)行緩慢，并且將直接減少總體吞吐量和降低性能 - 以及應(yīng)用程序處理大型并發(fā)性用戶負(fù)載的能力。

折衷

High Concurrency 策略解決了高并發(fā)性需求，因?yàn)樗軐⑹聞?wù)在體系結(jié)構(gòu)中的作用域盡可能減小。其結(jié)果是，事務(wù)會(huì)比在 API 層事務(wù)策略中更快地完成（提交或回滾）。但是，就像您從 Vasa 中學(xué)到的（見參考資料），您不能同時(shí)擁有它們。生活中充滿了折衷，事務(wù)處理也不例外。您不能期望提供與 API 層策略同樣可靠的事務(wù)處理，同時(shí)提供最大的用戶并發(fā)性和最高的吞吐量。

因此，您在使用 High Concurrency 事務(wù)策略時(shí)放棄了什么呢？根據(jù)您的應(yīng)用程序的設(shè)計(jì)，您可能需要在事務(wù)作用域外部執(zhí)行讀取操作，即使讀取操作用于更新目的。"等一等！"您說："您不能這樣做 - 您可能會(huì)更新在最后一次讀取之后發(fā)生了變化的數(shù)據(jù)！"這是合理的擔(dān)憂，并且也是需要開始考慮折衷的地方。通過此策略，由于您未對數(shù)據(jù)保持讀取鎖，因此在執(zhí)行更新操作時(shí)遇到失效數(shù)據(jù)異常的機(jī)率會(huì)增加。但是，與 Vasa 的情況一樣，所有這些都可以歸結(jié)為一個(gè)問題，即哪個(gè)特性更加重要：可靠、堅(jiān)固的事務(wù)策略（如 API 層策略），還是高用戶并發(fā)性和吞吐量。在高并發(fā)性情形中，同時(shí)實(shí)現(xiàn)兩者是極為困難的。如果您嘗試這樣做，則可能會(huì)適得其反。

第二個(gè)折衷之處是事務(wù)可靠性的總體缺乏。此策略難以實(shí)現(xiàn)，并且需要更長的時(shí)間進(jìn)行開發(fā)和測試，并且比 API 層或 Client Orchestration 策略更易于出錯(cuò)。考慮到這些折衷，您首先應(yīng)該分析當(dāng)前的情形以確定使用此策略是否是正確的方法。由于 High Concurrency 策略派生自 API 層策略，因此一種比較好的方法是先使用 API 層策略，并使用較高的用戶負(fù)載對應(yīng)用程序執(zhí)行負(fù)載測試（比您預(yù)期的峰值負(fù)載更高）。如果您發(fā)現(xiàn)吞吐量較低、性能較第、等待次數(shù)非常多，或者甚至出現(xiàn)死鎖，則要準(zhǔn)備遷移到 High Concurrency 策略。

在本文的其余部分，我將向您介紹 High Concurrency 事務(wù)策略的其他一些特性，以及實(shí)現(xiàn)它的兩種方法。

基本結(jié)構(gòu)和特性

圖 1 通過我在 事務(wù)策略系列中所使用的邏輯應(yīng)用程序棧展示了 High Concurrency 事務(wù)策略。包含事務(wù)邏輯的類顯示為紅色陰影。 圖 1 通過我在 事務(wù)策略系列中所使用的邏輯應(yīng)用程序棧展示了 High Concurrency 事務(wù)策略。包含事務(wù)邏輯的類顯示為紅色陰影。

圖 1. 體系結(jié)構(gòu)層和事務(wù)邏輯

一些 API 層策略的特性和規(guī)則是有效的 - 但并非所有。注意，圖 1 中的客戶機(jī)層沒有事務(wù)邏輯，這意味著任何類型的客戶機(jī)都可以用于此事務(wù)策略，包括基于 Web 的客戶機(jī)、桌面、Web 服務(wù)和 Java Message Service (JMS)。并且事務(wù)策略遍布于客戶機(jī)下面的層中，但這不是絕對的。一些事務(wù)可能在 API 層中開始，一些在業(yè)務(wù)層中開始，還有一些甚至在 DAO 層中開始。這種一致性的缺乏是造成策略難以實(shí)現(xiàn)、維護(hù)和治理的原因之一。

在大多數(shù)情況下，您會(huì)發(fā)現(xiàn)您需要使用Programmatic Transaction 模型 來減小事務(wù)作用域，但有時(shí)您仍然會(huì)使用Declarative Transaction 模型。但是，您通常不能在相同的應(yīng)用程序中混用 Programmatic 和 Declarative Transaction 模型。在使用這種事務(wù)策略時(shí)，不應(yīng)該堅(jiān)持使用這種 Programmatic Transaction 模型，這樣您就不會(huì)遇到各種問題。但是，如果您發(fā)現(xiàn)自己可以在此策略中使用 Declarative Transaction 模型，那么您應(yīng)該在使用 REQUIRED 事務(wù)屬性開始事務(wù)的層中標(biāo)記所有公共寫方法（插入、更新和刪除）。此屬性表示需要一個(gè)事務(wù)，并且如果事務(wù)不存在，則由方法啟動(dòng)。

與其他事務(wù)策略一樣，無論您選擇開始事務(wù)的組件或?qū)邮鞘裁?，啟?dòng)事務(wù)的方法都被認(rèn)為是事務(wù)擁有者。只要可能，事務(wù)擁有者應(yīng)該是對事務(wù)執(zhí)行提交和回滾的唯一方法。

事務(wù)策略實(shí)現(xiàn)

您可以使用兩個(gè)主要技巧來實(shí)現(xiàn) High Concurrency 事務(wù)策略。先讀?。╮ead-first）技巧涉及在盡可能高的應(yīng)用層（通常為 API 層）對事務(wù)作用域范圍外的讀取操作進(jìn)行分組。低級(jí)（lower-level）技巧涉及在體系結(jié)構(gòu)中盡可能低的層啟動(dòng)事務(wù)，同時(shí)仍然能夠更新操作的原子性和隔離。

先讀取技巧

先讀取技巧涉及重構(gòu)（或編寫）應(yīng)用程序邏輯和工作流，以便所有的處理和讀取操作在事務(wù)作用域的外部首先發(fā)生。這種方法消除了不必要的共享或讀取鎖，但是如果數(shù)據(jù)在您能夠提交工作之前更新或提交，則可能會(huì)引入失效數(shù)據(jù)異常。為了應(yīng)對可能的這種情況，如果在此事務(wù)策略中使用對象關(guān)系映射（ORM）框架，則應(yīng)確保使用了版本驗(yàn)證功能。

為了演示這種先讀取技巧，我們從一些實(shí)現(xiàn) API 層事務(wù)策略的代碼入手。在清單 1 中，事務(wù)在 API 層中開始，并且包圍了整個(gè)工作單元，包括所有的讀取、處理和更新操作：

清單 1. 使用 API 層策略

                           
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void processTrade(TradeData trade) throws Exception {
   try {
      //first validate and insert the trade
      TraderData trader = service.getTrader(trade.getTraderID());
      validateTraderEntitlements(trade, trader);
      verifyTraderLimits(trade, trader);
      performPreTradeCompliance(trade, trader);
      service.insertTrade(trade);

      //now adjust the account
      AcctData acct = service.getAcct(trade.getAcctId());
      verifyFundsAvailability(acct, trade);
      adjustBalance(acct, trade);
      service.updateAcct(trade);

      //post processing
      performPostTradeCompliance(trade, trader);
   } catch (Exception up) {
      ctx.setRollbackOnly();
      throw up;
   }
}

注意在 清單 1 中，所有的處理都包含在 Java Transaction API (JTA) 事務(wù)的作用域內(nèi)，包括所有的確認(rèn)、驗(yàn)證和兼容性檢查（提前和事后）。如果您通過探查器工具來運(yùn)行 processTrade() 方法，那么就會(huì)看到每個(gè)方法調(diào)用的執(zhí)行時(shí)間將與表 1 相似：

表 1. API 層方法探查 - 事務(wù)作用域

processTrade() 方法的持續(xù)時(shí)間稍微長于 6 秒 (6100 ms)。由于事務(wù)的起始時(shí)間與方法相同，因此事務(wù)的持續(xù)時(shí)間也是 6100 ms。根據(jù)您所使用的數(shù)據(jù)庫類型以及特定的配置設(shè)計(jì)，您將在事務(wù)執(zhí)行過程中保持共享和專用鎖（從執(zhí)行讀取操作開始）。此外，在由 processTrade() 方法調(diào)用的方法中執(zhí)行的任何讀取操作也可以在數(shù)據(jù)庫中保持一個(gè)鎖。您可能會(huì)猜想，在本例中，在數(shù)據(jù)庫中保持鎖持續(xù) 6 秒以上將不能擴(kuò)展以支持高用戶負(fù)載。

清單 1 中的代碼在沒有高用戶并發(fā)性或高吞吐量需求的環(huán)境中可能會(huì)非常出色地運(yùn)行。遺憾的是，這只是大多數(shù)人用于測試的一種環(huán)境。一旦此代碼進(jìn)入生產(chǎn)環(huán)境，其中數(shù)以百計(jì)的交易者（或者是全球的）都在進(jìn)行交易，則該系統(tǒng)最有可能會(huì)運(yùn)行得非常糟糕，并且極有可能會(huì)遇到數(shù)據(jù)庫死鎖（根據(jù)您所使用的數(shù)據(jù)庫而定）。

現(xiàn)在，我將修復(fù) 清單 1 中的代碼，方法是應(yīng)用 High Concurrency 事務(wù)策略的先讀取技巧。在清單 1 所示的代碼中，第一個(gè)要注意的地方是總共只用了 300 ms 的更新操作（插入和更新）。（此處，我假定 processTrade() 方法調(diào)用的其他方法不執(zhí)行更新操作。基本技巧是在事務(wù)作用域之外執(zhí)行讀取操作和非更新處理，并且僅將更新封裝在事務(wù)內(nèi)部。清單 2 中的代碼演示了減小事務(wù)作用域并仍然維持原子性的必要性：

清單 2. 使用 High Concurrency 策略（先讀取技巧）

                           
public void processTrade(TradeData trade) throws Exception {
   UserTransaction txn = null;
   try {
      //first validate the trade
      TraderData trader = service.getTrader(trade.getTraderID());
      validateTraderEntitlements(trade, trader);
      verifyTraderLimits(trade, trader);
      performPreTradeCompliance(trade, trader);

      //now adjust the account
      AcctData acct = service.getAcct(trade.getAcctId());
      verifyFundsAvailability(acct, trade);
      adjustBalance(acct, trade);
      performPostTradeCompliance(trade, trader);

      //start the transaction and perform the updates
      txn = (UserTransaction)ctx.lookup("UserTransaction");
      txn.begin();
      service.insertTrade(trade);
      service.updateAcct(trade);
      txn.commit();
   } catch (Exception up) {
      if (txn != null) {
         try {
            txn.rollback();
         } catch (Exception t) {
            throw up;
         }
      }
      throw up;
   }
}

注意，我將 insertTrade() 和 updateAcct() 方法移動(dòng)到了 processTrade() 方法的末尾，并將它們封裝在了一個(gè)編程事務(wù)中。通過這種方法，所有讀取操作和相應(yīng)的處理將在事務(wù)的上下文之外執(zhí)行，因此不會(huì)在事務(wù)持續(xù)時(shí)間內(nèi)在數(shù)據(jù)庫中保持鎖。在新代碼中，事務(wù)持續(xù)時(shí)間只有 300 ms，這顯著低于 清單 1 中的 6100 ms。再次，其目標(biāo)是減少在數(shù)據(jù)庫中花費(fèi)的時(shí)間，從而減少數(shù)據(jù)庫的總體并發(fā)性，以及應(yīng)用程序處理較大并發(fā)用戶負(fù)載的能力。通過使用 清單 2 中的代碼將數(shù)據(jù)庫占用時(shí)間減少至 300 ms，從理論上說，吞吐量將實(shí)現(xiàn) 20 倍的提升。

如表 2 所示，在事務(wù)作用域中執(zhí)行的代碼至減少至 300 ms：

表 2. API 層方法探查 - 修改后的事務(wù)作用域

雖然這從數(shù)據(jù)庫并發(fā)性的角度來說是一種顯著的改善，但先讀取技巧帶來了一個(gè)風(fēng)險(xiǎn)：由于為更新指定的對象上沒有任何鎖，因此任何人都可以在此 LUW 過程中更新這些未鎖定的實(shí)體。因此，您必須確保被插入或更新的對象一般情況下不會(huì)由多個(gè)用戶同時(shí)更新。在之前的交易場景中，我做了一個(gè)安全的假設(shè)，即只有一個(gè)交易者會(huì)在特定的時(shí)間操作特定的交易和帳戶。但是，并非始終都是這種情況，并且可能會(huì)出現(xiàn)失效數(shù)據(jù)異常。

另外需要注意：在使用 Enterprise JavaBeans (EJB) 3.0 時(shí)，您必須通知容器您計(jì)劃使用編程事務(wù)管理。為此，您可以使用 @TransactionManagement(TransactionManagementType.BEAN) 注釋。注意，這個(gè)注釋是類級(jí)的（而不是方法級(jí)的），這表示您不能在相同的類中結(jié)合 Declarative 和 Programmatic 事務(wù)模型。選擇并堅(jiān)持其中之一。

低級(jí)技巧

假設(shè)您希望堅(jiān)持使用 Declarative Transaction 模型來簡化事務(wù)處理，但是仍然能在高用戶并發(fā)性場景中增加吞吐量。同時(shí)，您應(yīng)該在這種事務(wù)策略中使用低級(jí)技巧。通過此技巧，您通常會(huì)遇到與先讀取技巧相同的折衷問題：讀取操作通常是在事務(wù)作用域的外部完成的。并且，實(shí)現(xiàn)這種技巧最有可能需要代碼重構(gòu)。

我仍然從 清單 1 中的示例入手。不用在相同的方法中使用編程事務(wù)，而是將更新操作移動(dòng)到調(diào)用棧的另一個(gè)公共方法中。然后，完成讀取操作和處理時(shí)，您可以調(diào)用更新方法；它會(huì)開始一個(gè)事務(wù)，調(diào)用更新方法并返回。清單 3 演示了這個(gè)技巧：

清單 3. 使用 High Concurrency 策略（低級(jí)技巧）

                           
@TransactionAttribute(TransactionAttributeType.SUPPORTS)
public void processTrade(TradeData trade) throws Exception {
   try {
      //first validate the trade
      TraderData trader = service.getTrader(trade.getTraderID());
      validateTraderEntitlements(trade, trader);
      verifyTraderLimits(trade, trader);
      performPreTradeCompliance(trade, trader);

      //now adjust the account
      AcctData acct = service.getAcct(trade.getAcctId());
      verifyFundsAvailability(acct, trade);
      adjustBalance(acct, trade);
      performPostTradeCompliance(trade, trader);

      //Now perform the updates
      processTradeUpdates(trade, acct);
   } catch (Exception up) {
      throw up;
   }
}

@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void processTradeUpdates(TradeData trade, AcctData acct) throws Exception {
   try {
      service.insertTrade(trade);
      service.updateAcct(trade);
   } catch (Exception up) {
      ctx.setRollbackOnly();
      throw up;
   }
}

通過此技巧，您可以有效地在調(diào)用棧的較低層次開始事務(wù)，從而減少花費(fèi)在數(shù)據(jù)庫中的時(shí)間。注意，processTradeUpdates() 方法僅更新在父方法（或以上）中修改中創(chuàng)建的實(shí)體。再次，保持事務(wù)的時(shí)間不再是 6 秒，您只需要 300 ms。

現(xiàn)在是最難的部分。與 API 層策略或 Client Orchestration 策略不同，High Concurrency 策略并未使用一致的實(shí)現(xiàn)方法。這便是 圖 1 看上去為何像一名經(jīng)驗(yàn)豐富的曲棍球員（包括缺少的牙齒）的原因。對于一些 API 調(diào)用，事務(wù)可能會(huì)在 API 層的末端開始，而其他時(shí)候，它可能僅限于 DAO 層（特別是對于 LUW 中的單表更新）。技巧是確定在多個(gè)客戶機(jī)請求之間共享的方法，并確保如果某個(gè)事務(wù)是在較高級(jí)的方法中開始的，則它將在較低級(jí)的方法中使用。遺憾的是，此特性的效果是，作為非事務(wù)擁有者的較低級(jí)方法可以對異常執(zhí)行回滾。結(jié)果，開始事務(wù)的父方法不能對異常采取正確的措施，并且在嘗試回滾（或提交）已經(jīng)標(biāo)記為回滾的事務(wù)時(shí)會(huì)出現(xiàn)異常。

實(shí)現(xiàn)指南

有些情況僅需要稍微小些的事務(wù)作用域來滿足吞吐量和并發(fā)性需求，而另一些情況需要大大縮小事務(wù)作用域來實(shí)現(xiàn)所需的目的。不管具體情況如何，您都可以遵循以下的實(shí)現(xiàn)指導(dǎo)，它們能夠幫助您設(shè)計(jì)和實(shí)現(xiàn) High Concurrency 策略：

• 在著手使用低級(jí)別技術(shù)之前，首先要從先讀技術(shù)開始。這樣，事務(wù)至少包含在應(yīng)用程序架構(gòu)的 API 層，并且不擴(kuò)散到其他層中。
  
  
• 當(dāng)使用聲明性事務(wù)時(shí)，經(jīng)常使用 REQUIRED 事務(wù)屬性而不是 MANDATORY 事務(wù)屬性來獲得保護(hù)，避免啟動(dòng)某個(gè)事務(wù)的方法調(diào)用另一個(gè)事務(wù)方法。
  
  
• 在采用此事務(wù)策略之前，確保您在事務(wù)作用域外部執(zhí)行讀取操作時(shí)是相對安全的。查看您的實(shí)體模型并問自己多個(gè)用戶同時(shí)操作相同的實(shí)體是常見的、少見還是不可能的。舉例來說，兩個(gè)用戶可以同時(shí)修改相同的帳戶嗎？如果您的回答是常見，則面臨著極高的失效數(shù)據(jù)異常風(fēng)險(xiǎn)，那么這個(gè)策略對于您的應(yīng)用程序探查來說是一個(gè)很差的選擇。
  
  
• 并不需要讓所有 讀取操作都處于事務(wù)作用域之外。如果有一個(gè)特定的實(shí)體經(jīng)常會(huì)被多個(gè)用戶同時(shí)更改，則應(yīng)該想盡一切辦法將它添加到事務(wù)作用域中。但是應(yīng)該清楚，添加到事務(wù)作用域中的讀取操作和處理越多，吞吐量和用戶負(fù)載功能的下降就越大。

結(jié)束語

一切都?xì)w結(jié)于如何在問題之間取得折衷。為了在應(yīng)用程序或子系統(tǒng)中支持高吞吐量和高用戶并發(fā)性，您需要高數(shù)據(jù)庫并發(fā)性。要支持高數(shù)據(jù)庫并發(fā)性，則需要減少數(shù)據(jù)庫鎖，并盡可能縮短保持資源的時(shí)間。某些數(shù)據(jù)庫類型和配置可以處理一些這種工作，但在大多數(shù)情況下，解決方案最終歸結(jié)為如何設(shè)計(jì)代碼和事務(wù)處理。對這些問題有一些了解之后，您在稍后可以更加輕松地完成復(fù)雜的重構(gòu)工作。選擇正確的事務(wù)策略對應(yīng)用程序的成功至關(guān)重要。對于高用戶并發(fā)性需求，可以使用 High Concurrency 事務(wù)策略作為確保高水平數(shù)據(jù)完整性，同時(shí)維持高并發(fā)性和吞吐量需求的解決方案。

參考資料

學(xué)習(xí)

• Java Transaction Design Strategies（Mark Richards，C4Media Publishing，2006 年）：這是本文作者所著的一本圖書，深入討論了 Java 平臺(tái)上的事務(wù)。
  
  
• Vasa：了解 Vasa（Wikipedia）的真實(shí)故事，并閱讀 " Architectural Tradeoffs"（Mark Richards，97 Things，July 2008），它演示了采用兩全策略時(shí)所發(fā)生的情況。
  
  
• Enterprise JavaBeans 3.0 (5th Edition)（Bill Burke 和 Richard Monson-Haefel）：這本優(yōu)秀的書能幫助您迅速掌握 EJB 3.0。
  
  
• Java Transaction Processing（Mark Little，Prentice Hall，2004）：本書是關(guān)于事務(wù)的另一本優(yōu)秀參考書。
  
  
• "Java 理論與實(shí)踐: 理解 JTS"（Brian Goetz，developerWorks，2002 年）：通過這份共 3 部分的系列文章了解 Java EE 事務(wù)處理的基礎(chǔ)。
  
  
• Chapter 9. Transaction management：Spring Framework 2.5 文檔的此部分提供了關(guān)于 Spring 事務(wù)處理的更多信息。
  
  
• Java EE APIs and Docs：可以在這里找到有關(guān) EJB 3.0 規(guī)范的文檔。
  
  
• 瀏覽 技術(shù)書店，查找關(guān)于這些主題和其他技術(shù)主題的圖書。
  
  
• developerWorks Java 技術(shù)專區(qū)：可以找到幾百篇關(guān)于 Java 編程的各個(gè)方面的文章。
  
  

討論

• 參與 My developerWorks 社區(qū)。

轉(zhuǎn)自：http://www.ibm.com/developerworks/cn/java/j-ts5/index.html?ca=drs-cn-0731

2.通過命令行臨時(shí)加載
mount -t cifs //10.1.27.195/linux /opt/other -o username=XXX,password=xxx,rw
通過 umount /opt/other 來卸載共享

具體命令來通過 man mount來查看。

官方網(wǎng)址：http://www.ispringsolutions.com/

我們可以下載免費(fèi)的PPT轉(zhuǎn)換軟件：iSpring Free

下載之后，按提示一步步安裝，安裝完成之后打開PowerPoint可以看見多了一行菜單

點(diǎn)擊Publish就可以將PPT轉(zhuǎn)換成Flash了：

最終我們可以得到我們需求的swf文件，直接嵌入到頁面中去就可以訪問了：

Flickr : PPT轉(zhuǎn)換成Flash

1.http://pixlr.com/editor/

• 支持中文界面，整體操作界面同Photoshop相似。
• 支持濾鏡。

2. http://www.splashup.com/splashup/

• 全英文界面，操作界面同Phtotshop，所以上手不難。

• 支持濾鏡

• 支持從各大圖片網(wǎng)站上提取圖片

• 界面比較美觀，所以使用起來比較順心。

快速入門

1.添加賬戶

2.撰寫博客

點(diǎn)擊"撰寫"進(jìn)入到博客撰寫頁：

撰寫完成之后，點(diǎn)擊"保存"將當(dāng)前文章放到本地草稿箱中去，點(diǎn)擊"發(fā)布"將直接發(fā)布博客到線上中去。

相關(guān)資料

1. 詳細(xì)的幫助文檔（英文）
2. 中文幫助文檔
3. 其他博客介紹的10款博客離線編輯器