创建 WebLogic 配置 / 域

域是一组逻辑上相关的 WebLogic Server 资源，您可以把它当作单个管理单元进行管理。域将所有的资源和应用程序信息保存在一个基于 XML 的配置库中。为了在 WebLogic Server 上部署并运行应用程序，首先要创建域。
 
推荐使用域配置向导作为创建新域的工具。如果您准备编写脚本来创建域，推荐使用slient模式的域配置向导这个工具。也可以从所提供的“开箱即用”的域模板或定制的域模板来创建WebLogic Server域。
 
为了创建定制的域模板，请使用配置模板生成器，它是一个单机的Java应用程序，能够让您创建定制的配置和扩展。您可以使用这些配置和扩展来创建和更新域。

域配置向导具有以下属性：

·   向导会引导您完成针对目标环境创建或扩展域的过程。

·   向导可以使用 OOB 预定义的域模板或定制域模板创建或扩展域。

·   向导将创建 config.xml 文件，建立基本的安全性，构造启动脚本，等等。

·   可以使用 graphical 、 console 或 silent 模式启动向导。

要以 graphical 模式启动向导，请运行以下命令之一：


域配置模板生成器具有以下属性：  

·   向导会引导您完成创建或扩展配置模板 (JAR file) 的过程。

·   配置向导可以使用已创建的配置（域）模板来创建域。

只能以 graphical 模式启动配置模板生成器。
要启动配置模板生成器，请运行以下命令之一：



技巧

·   如果 WebLogic Domain/Configuration 分布在多台物理机器上，那么应该只能在管理服务器硬件（机器）上运行域配置向导。

·   并不要求一定在托管服务器硬件上运行域配置向导。  

·   在 WebLogic Server 安装目录之外创建 WebLogic 域 ( 默认情况下，所创建的域位于 %BEA_HOME%Ser_projectsdomains ) 。

·   为管理服务器创建启动脚本时，如果脚本 (startWebLogic.cmd/sh) 没有调用域目录中的 weblogic.Server 类，使用这个命令行选项来指定域的位置： -Dweblogic.RootDirectory=path 。

·   启动托管服务器 (startManagedWebLogic.cmd/sh) 时，如果进行设置的话， -Dweblogic.RootDirectory 将被设置为服务器根目录，该目录将被用于存储文件，比如日志文件和托管服务器独立（ managed-server independence ， MSI ）文件。

服务器启动
 
管理服务器从配置库(config.xml)加载所有配置。所有相关的托管服务器必须在启动期间连接到运行中的管理服务器。独立的托管服务器可以从本地库(msi-config.xml)加载配置。
 
如果WebLogic运行在装有Unix操作系统的计算机上，您可以为WebLogic Server进程分配一个UID或GID，以便在计算机执行所有优先的启动操作之后，以root用户的身份进行绑定。如果WebLogic Server用户想要绑定到更高的端口(>1024)，则无需root权限。

技巧
编写使服务器启动自动化的脚本时，考虑以下因素：

·   在域中，必须在任何相关托管服务器之前启动管理服务器。

·   当把托管服务器作为相关服务器启动时，它连接到管理服务器，以便下载配置。

·   当把托管服务器作为独立服务器启动时，检查 msi-config.xml 文件是否被存储在服务器根目录中。

·   在 Unix 中，使用 'nohup' 运行 WebLogic Server 启动脚本，以保证即使您注销以后，服务器依然在后台运行。

·   在 OS 中，为安装和启动服务器创建一个 WebLogic Server 用户。

·   存储加密后的用户身份，使用 boot.properties 文件来避免启动脚本中出现硬编码的用户身份。

·   当把服务器绑定到较低端口 (<1024) 时（这需要 root 权限），使用 WebLogic UNIX 机器配置来绑定 UID 或 GID 。

·   为了使 WebLogic 域中的管理服务器在机器重启期间能够自动重启，使用操作系统提供的 daemon 进程功能。

o               Windows 服务

o               UNIX daemon 进程

·   当您使用域配置向导创建域时，域中的管理服务器可以被当成服务。

·   此外，可以使用位于域文件夹中的 installservice.cmd 和 uninstallservice.cmd 脚本在 Windows Service Control Manager (SCM) 中添加或删除服务。

·   如果管理服务器和托管服务器是同一台机器，配置管理服务器进程和托管服务器进程之间的 OS 级服务相关性。

·   配置 rc 脚本，以便在正确的运行级别上添加 WebLogic 启动命令。

启动和关机类
可以把 WebLogic Server 配置为在启动和正常关机过程中调用类。在服务器初始化所有子系统之后和它给客户端访问开放端口之前，加载并执行启动类。类似地，在服务器启动正常关机进程之前加载关机类。和应用程序文件不同，必须手动地使启动和关机类在已部署服务器地本地 classpath 中可用。

技巧

·   在启动期间，使服务器级的启动类在已部署 WebLogic Server 实例的系统 classpath 中可用。

·   域中的管理服务器到托管服务器都不能自动部署出现在系统 classpath 中的类；应用程序级别的类可以分布在域中的管理服务器到目标服务器上。

·   重新部署应用程序时，就会重新加载应用程序级别的启动类。

·   不能动态地重新加载服务器级别的启动类；只能在它们各自的 WebLogic Server 重新启动时重新加载它们。

·   使用应用程序级别的启动类，而不要定义服务器级别的启动类。

节点管理器
使用 WebLogic Server 提供的节点管理器功能自动启动托管服务器，或者重新启动出现故障的托管服务器。节点管理器使管理员可以从管理服务器或命令行 (weblogic.Admin START…) 远程启动托管服务器。这可以通过与管理服务器通信来实现，而不用依赖 OS 特定的远程登录功能。
 
此外，除了启动和关闭托管服务器之外，节点管理器还能够监控它所启动的服务器的健康状况。如果进行恰当的配置，在出现故障时，节点管理器能够自动重新启动托管服务器。

技巧

·   使用节点管理器时，显式地配置所托管服务器的有远程启动属性，而不要依靠节点管理器为托管服务器的配置提供的环境。

·   节点管理器只接收来自管理服务器的请求。管理服务器不可用时，想要通过节点管理器远程地重新启动托管服务器是不可能的。

·   把节点管理器配置为一个服务 / daemon 。

·   启用托管服务器的自动重启。

·   配置机器在出现故障时自动关闭，以便在节点管理器尝试重新启动一个出现故障的实例之前关闭它。

·   运行在一台机器上的节点管理器可以被运行在该机器上的多台托管服务器所共享。

·   节点管理器还可以被运行在同一台机器上的多个域中的托管服务器所共享。

WebLogic Server 关闭过程
异常的 JVM 终止可以导致套接字或程序段这样的资源被锁定。在操作系统中关闭或终止 WebLogic Server 进程被认为是异常终止。
可以通过以下方式正常关闭 WebLogic Server ：

·   使用管理控制台 'Graceful Shutdown" 超链接。

·   使用 weblogic.Admin SHUTDOWN… 命令。

·   使用 JMX ，具体是调用 ServerMBean 类的 stop 方法。

技巧

·   为了正常关闭生产服务器，需要使用 WebLogic 管理控制台或者 weblogic.Admin 实用程序。

·   正常关机不会异常终止用户会话；它等待 HTTP 会话完成或超时。

·   也可以把 WebLogic Server 配置为不等待（忽略 Session During Shutdown 选项）。

·   正常关机超时是可配置的；默认情况下，服务器将会无限期地等待关机过程完成。

·   如果服务器没有响应正常关机请求，或者当服务器等待正在进行的会话时（处于待机状态）关闭服务器，使用 'Force Shutdown' 选项。

·   如果被配置为 daemon ，确保将 rc 脚本中的 stop 方法配置为在机器重启和停止时正常关闭服务器。

·   如果对节点管理器进行配置，终止节点管理器将不会停止由它们启动的相应服务器。必须单独地停止各台托管服务器。

备份和恢复
为了在出现故障时迁移或恢复 WebLogic 域，定期备份管理服务器机器上的整个域目录树。这样，您就可以从硬件或系统故障中恢复，而要做的不过是还原域目录并重新启动管理服务器。
 
如果管理服务器崩溃，管理服务器将会把所有正在运行的托管服务器的相关信息保留在running-managed-servers.xml文件中。重新启动时，管理服务器将会读取这个文件，并尝试联系所有以前运行的托管服务器。如果没有托管服务器正在运行的话，discovery模式可能会增加管理服务器的启动时间，但是始终要使用discovery模式（默认情况下它是打开的），这样才能保证有托管服务器已经运行的情况下，管理服务器重新与所有托管服务器连接。

一些需要引起注意/定期从管理服务器机器上进行备份的重要文件有：

·   config.xml
域配置库。

·   config.xml.booted
成功启动时对域配置库的良好备份。

·   boot.properties
启动管理服务器时需要的加密后的用户名和密码。

·   running-managed-servers.xml
这是当前正在运行的相关托管服务器的一个列表。这个文件用于当管理服务器重新启动后，而且有托管服务器正在运行时，发现托管服务器。

·   domain/configArchive/
包含域配置库文件的拷贝。使用管理工具进行更新时，管理服务器把旧的 config.xml 文件复制到这个目录。

·   domaindminserverdapdapfiles
当前被域的管理服务器使用的内嵌 LDAP 数据文件。

·   *.ldift 文件
这些文件可以用于把 WebLogic Domain Embedded LDAP 服务器初始化为刚刚创建域时的样子。

·   domain/adminserver/ldap/backup/EmbeddedLDAPBackup.zip
WebLogic Domain Embedded LDAP 服务器的备份。内嵌的 LDAP 被用于存储用户、组、角色、默认的安全领域使用的策略、 myrealm 的安全提供程序。

·   Batch/Shell 脚本
setEnv.cmd/sh, startWebLogic.cmd/sh, startManagedWebLogic.cmd/sh 。

  为管理任务编写脚本
为了创建用于管理域配置的脚本：

·   使用 weblogic.Admin 实用程序命令 BATCHUPDATE ，它运行一个批处理文件中指定的一系列命令。这个命令使用一个 JVM 运行所有列出的命令。

·   -Dweblogic.system.BootIdentityFile 选项让您可以避免把用户名和密码硬编码在您的文本脚本中。

·   为了在操作系统脚本中构建逻辑分支，使用下面的命令求出 weblogic.Admin 命令的返回代码：

o               %ERRORLEVEL% (Windows)

o               0 (bash shell)

·    weblogic.Admin 的-adminurl 选项从管理服务器检索托管服务器的配置Mbean和运行时Mbean。

·   不推荐直接修改 config.xml 文件。

·   如果您必须修改 config.xml 文件：

o               首先，在编辑之前备份原始文件。

o               使用 XML 编辑器，以避免录入错误。

o               当管理服务器正在运行时，要避免编辑该文件。

·   使用 wlconfig Ant 任务来为配置信息编写脚本，并把它集成到整个构建过程中。

·   当管理服务器正在运行并且处于离线状态时，使用 WebLogic Scripting Tool (WLST) 来修改域配置。 (dev2dev.bea.com)

·   WLST 提供一个功能强大的到 WebLogic Server 的 shell 接口，而且它使用 Jython 作为脚本语言。

·   您还可以使用第三方的解决方案来管理配置，比如 WLShell 使用程序。 (www.wlshell.com)

·   WLShell 提供一个功能强大的、 Unix 风格的到 WebLogic Server 的 shell 接口；它针对 WebLogic Server MBean 使用文件系统模拟 。

日志记录
日志记录了和事件（比如服务器的启动和关闭）、新应用程序的部署或者一个或多个子系统故障有关的信息。日志消息包括和事件的时间与日期，以及启动事件用户的 ID 有关的信息。每个 WebLogic Server 实例都可以维护一份服务器日志、一份 HTTP 访问日志、一份 JDBC 日志和一份 JTA 事务日志。

技巧

·   为了防止当日志文件所占空间过大时，出现相应的服务器重启的情况，需要启用日志旋转（ log rotation ）。

·   考虑按照大小旋转日志，而不是按照生成的时间旋转，因为使用生成时间这个选项会使文件增长非常迅速。

·   如果您没有进行交互式调试，而且 WebLogic Server 是在后台（ Windows 或 Unix ）启动的，使用以下命令把 stdout 和 stderr 重定向到一个文件：

o               -Dweblogic.Stdout="stdout-filename"

o               -Dweblogic.Stderr="stderr-filename"

·   在生产中，如果您不启用 WebLogic Server 创建 JDBC 日志，您就可以避免服务器上的额外文件 I/O 。

·   使用节点管理器启动托管服务器时，节点管理器捕捉服务器的 stdout 并把它存储到一个文件中。可以使用管理控制台来查看该文件的内容。

·   经常检查 WebLogic Server 的日志文件，以熟悉常规操作，这样您就能够很容易地辨认出异常的日志项。

JDBC
在 WebLogic Server 中，使用池缓冲到数据库的 JDBC 连接可以提高应用程序的性能。连接池根除了为每个应用程序创建新的数据库连接的需要。 JDBC 连接池提供到您数据库的现成连接。
 
使用连接池时，到数据库的连接的数目可以动态改变。但是，在负载高峰时期试图增加JDBC连接的数目将会使情况恶化，因为创建数据库连接是一项开销昂贵的操作。
 
连接池还可以通过缓存用于重用的prepared statement和callable statement来提高性能。重用prepared statement和callable statement可以降低数据库服务器上的CPU利用率。
 
通过把其他应用程序分离到单独的机器或硬件上，可以避免耗尽WebLogic Server机器上的处理能力；为数据库指派一台专用的机器。

技巧

·   如果有可能，按大小排列数据库连接池，这样它们就永远不会增加连接的数目；设置初始容量为最大容量。

·   设置连接池的最大容量至少等于执行线程的数量。

·   配置 Inactive Connection Timeout ，以指定一个连接在被回收到池中之前，保持非活动状态的时间长短。

·   Connection Leak Profiling 选项显示了连接池中泄漏的连接。 BEA 建议您不要在生产中使用这个选项；它要使用额外的资源，并且通常会降低连接池操作的速度。

·   如果您能够负担把测试连接作为常规请求处理一部分所带来的开销，您可以只使用 Test Reserved Connections 选项。

·   避免对“ Test Table Name ”使用生产表，而要使用哑表 ( 例如 Dual) 。

·   使用语句缓存提高 prepared 和 callable statement 的性能。

·   为缓存选择 least-recently-used (LRU) 算法；这将从缓存中删除很少使用的语句。

·   当创建连接池或者启动 WebLogic Server 时，如果数据库不可访问，可以使用 Connection Creation Retry Frequency 重新尝试建立到数据库的连接。

·   当 WebLogic Server 正在运行时，如果重新启动数据库， Test Frequency 可以从 0 开始增加，这样所有连接都会被关闭，然后被重新打开，以重新建立有效的物理连接。在重新创建所有连接之后，将它改回 0 将禁止测试。

·   当为连接池使用 DataSource 对象时，使用 Honors Global Transaction 选项来创建 TxDataSource 。

·   您应该使用 non-Tx DataSource 的惟一场合就是当您想在数据库上完成一些工作，而又不想把该数据库包括到当前事务中时。

·   当配置一个连接池，以便与 WebLogic JMS JDBC Store 一起使用时，使用 non-XA 数据库驱动程序。

JMS
WebLogic Server JMS 体系结构允许在一个 WebLogic 域中创建多台 JMS 服务器。但是每台 JMS 服务器只能在一台 WebLogic Server 上被实例化（目标化），因为它是一项“仅一次”的服务。一台 JMS 服务器可以作为多个目的地的宿主。永久性存储（基于磁盘的文件或可通过 JDBC 访问的数据库）可以被配置用于存储永久性的消息数据。
 
如果必须跨多个目的地共享一个JMS存储器，将多个目的地配置为驻留在一台JMS服务器上。但是，为了使用对每个目的地使用单独的永久性存储器，在多台JMS服务器下创建它们。

技巧

·   针对 JMS 文件存储启用直接写入同步写入策略，这可以释放虚拟内存（ VM ）堆，但是只有当存在一些并发的活动 JMS 客户端时，直接写入可以显著地提高性能。

·   在单独的磁盘上，或者甚至是在单独的磁盘控制器上分离文件存储。

·   为了使文件存储高度可用，您可以使用 Storage Area Network (SAN) ，一种多端口的磁盘或者磁盘镜像技术。

·   不要把使用 XA JDBC 驱动程序的连接池与 JMS JDBC 存储器关联起来，因为 JMS JDBC 存储器不支持 XA 资源驱动程序 (WebLogic JMS 实现了它自己的 XA 资源 ) 。

·   使用 Using Expiration Scan Interval 扫描目的地的到期消息可以释放 VM ，但是太频繁的扫描会增加扫描开销；确保您对此做最优调整。

·   在连接工厂上设置 MessagesMaximum ，以便调整异步消息管道的大小。

·   为了避免消息增长，在连接工厂级别上设置 Time To Live 属性。

·   禁用默认的 JMS 连接工厂；针对生产配置特定于应用程序的 JMS 连接工厂。

·   为跨物理目的地（在不同的 JMS 服务器中进行配置）的负载平衡 JMS 消息配置一个分布式的目的地。

·   当部署分布式目的地时，针对群集中的每台 JMS 服务器和成员目的地使用类似的设置。

消息分页
永久性和非永久性消息消耗服务器内存，除非启用分页。消息分页是释放永久性和非永久性消息所占用的服务器内存的过程，因为永久性消息也会把它们的数据缓存在内存中。一条被换出页面的消息不会释放它使用的所有内存。消息头和消息属性仍然留在内存中，以供查找、排序和过滤之用。在事务性会话中发送的消息只有在会话被提交后才适合于分页。在这之前，消息被保存在内存中。

技巧

·   如果启用 JMS 分页，而且没有配置分页存储器， WLS 8.1 会自动创建一个分页存储器，但是推荐显式地配置页面存储器（您可以指定存储器的位置）。

·   JMS 分页增加了一个 WebLogic Server 实例能够包含的消息数据的数量，而不要求增加 JVM 堆大小。

·   分页的确会降低性能，但是对非永久性消息进行分页时，其效果比对永久性消息分页时要小。

·   始终为 WebLogic JMS Server 配置限额；限额可以防止消息溢出服务器内存。

流控制
定义 JMS 服务器之后，您可以配置一个或多个连接工厂，以使用预定义的属性创建连接。借助流控制功能，您可以在消息生产程序确定自己将会变得过载时，引导 JMS 服务器或目的地降低它的速度。

技巧

·   为了降低过于活跃的、从 WebLogic Server 进程之外淹没目的地的生产程序的速度，需要配置流控制。

·   在服务器内部使用流控制会导致服务器线程速度变慢；要小心使用。

部署
WebLogic Server 允许您把部署单元存储为单个存档文件，或者是一个包含与上述存档文件相同内容的已展开目录。存档文件是包含一个所有应用程序或模块的类、静态文件、目录和部署描述符文件的单个文件。
 
在托管服务器实例上部署用户应用程序。这将管理应用程序（控制台）和域配置从用户应用程序分离出来。在生产环境和多服务器环境中，避免使用应用程序的自动部署。以“生产模式”运行WebLogic域将禁止在生产中进行自动部署。如果您创建脚本来把应用程序部署为整个结构的一部分，考虑使用wldeploy Ant任务。

如果您在部署应用程序（或模块）时，在把On Future Redeploys选项设置为Initialize Roles and Policies From DD 之前，一次或多次将其设置为Ignore Roles and Policies From DD，您就可以使用管理控制台设置安全策略和安全角色。但是，使用管理控制台进行的这些修改将覆盖部署描述符中指定的安全性。

技巧

·   使用生产模式运行生产应用程序。

·   避免在管理服务器实例上部署用户应用程序。

·   为了指定服务器的默认 Web 应用程序，在 weblogic.xml 或 application.xml 文件中使用一个空的 context-root 元素或者一个值为 "/" 的元素。

·   在管理控制台中部署应用程序之后，对该应用程序的安全策略的修改将会覆盖部署描述符中的策略。

重新部署
部署一个应用程序之后，您可以重新部署该应用程序本身或者它的一部分。重新部署一个完整的应用程序包括卸载它所有的类，然后使用修改后的文件再次部署该应用程序。在生产中重新部署应用程序是一个很严肃的任务，它可能影响到性能，所以要仔细规划应用程序的更新。
 
如果生产中有一个Web应用程序正在使用中，重新部署将导致WebLogic Server丢失所有活动的HTTP会话。通过在WebLoigc特定的部署描述符文件(weblogic.xml)中打开一个特殊的属性，可以还原HTTP会话。

技巧

·   如果您只修改了静态文件，那么在不用重新部署整个应用程序的情况下刷新它们是可能的。

·   使用命令行选项部分地重新部署已扩展的应用程序 (weblogic.Deployer … -redeploy <files>…) 。

·   想要在不改变应用程序的情况下修改部署参数，需要使用备用的部署描述符。

·   为了简化在重新部署期间，把应用程序存档文件重新分布到多个 WebLogic Server 实例上的过程，需要使用分段模式部署。

·   如果管理服务器不可用，可以以独立模式启动具有全部分段应用程序的托管服务器，并使它的功能完全。

企业应用程序
如果客户端位于相同的企业级应用程序类中，而且可以在企业应用程序中跨所有存档应用程序共享库， WebLogic 优化了对 EJB 的访问。所以，考虑创建企业存档文件，而不是独立部署相关的应用程序。此外还可以使用企业范围内的设置，而不要使用部署描述符中的多项本地设置。使用 WebLogic 控制台在 WebLogic Server 域中创建 JDBC 资源，而不要采用 weblogic-application.xml 技术。

技巧

·   在 WebLogic Server 中，避免把 EJB 存档文件和相关 Web 应用程序部署为单独的独立应用程序。

·   当 Web 组件访问同一个企业应用程序中的 EJB 组件时，可以提高运行时性能。

·   可以把企业部署为一个部署单元。

·   不要把特定于应用程序的类或 JAR 文件放入系统 classpath ( 避免为了重新加载它们而不得不重新启动服务器 ) 。

·   使用 WebLogic Server 8.1 时，请使用企业应用程序目录结构中新的 APP-INF/lib 和 APP-INF/classes 目录，这是为了简化实用程序类和实用程序存档文件的打包工作。

预编译
生产和测试部署应该包括经过预编译的 JSP 页面和 EJB （使用 weblogic.appc ，如果是早期的 weblogic 版本则使用 weblogic.jspc /weblogic.ejbc ）。在您部署应用程序之前的很长一段时间内，它们可以捕捉该应用程序的错误。此外，离线编译可以验证部署描述符与当前规范的兼容性。部署已编译的应用程序可以缩减部署时间和接下来的服务器重启时间。用在开发人员的工作站上的开发部署可以使用动态编译。

技巧

·   为了在应用程序部署期间或服务器启动期间预先编译 JSP 文件，在 weblogic.jar 中启用预编译参数。

·   在生产环境中，要禁止运行时的页面检查和重新编译，需要把 pageCheckSeconds 设定为 -1 。

·   您可以使用 weblogic.appc 或 weblogic.ejbc ( 不再使用 ) 在服务器 VM 之外编译 EJB 。这可以减少随后服务器的重启时间。

·   在脚本中使用 weblogic.Deployer 实用程序，或者它相关的 Ant 任务 wldeploy ，以便在生产环境中使部署自动化。

部署描述符编辑
只有当重新部署应用程序时，修改 J2EE 应用程序的部署描述符才会生效。 WebLogic 管理控制台提供一种方法来修改某些部署描述符属性，而不用重新部署应用程序。当域以开发模式运行时，为了利用这项功能，您必须在已展开的目录结构中部署应用程序（非存档格式）。
 
为了在部署之后修改应用程序的描述符值（以展开的格式），执行以下操作：Web Application Module > Your Application > Configuration 选项卡 > Descriptor选项卡。

技巧

·   使用 WebLogic Server 提供的工具生成和编辑 XML 部署描述符。

·   WebLogic Builder 生成描述符；它包括一个用于编辑描述符的接口。

·   DDInit 是一个命令行实用工具，用于为 WebLogic Server 应用程序生成部署描述符。

·   ddcreate 是一个 Ant 任务，可以用于为企业应用程序创建部署描述符。

EJB
无状态会话 EJB 自由池可以提高性能和吞吐量，因为 bean 是在服务器启动期间或部署期间被创建的。 WebLogic Server 使用 bean 实例的缓存来提高有状态会话 EJB 的性能。该缓存在内存中存储活动的 EJB 实例，这样它们马上就可以为客户端请求所用。
 
使用应用程序级/联合缓存将导致碎片减少，而且内存和堆空间的利用率更高。但是应用程序级/联合缓存的使用仅限于企业应用程序中的实体EJB。对于要求高吞吐量的应用程序来说，要使用bean级别的缓存。bean级缓存是高效的，因为任务们不用竞争对联合缓存中一个控制线程的控制权。

为了在应用程序中使用WebLogic为EJB组件提供的调用优化，把<enable-call-by-reference>设置为true。
 
在同一个企业应用程序中为要访问的EJB编写本地接口，也可以达到相同的目的。
 
实体EJB的并发策略包括：

数据库：
遵从数据库可以提高吞吐量（对于 EJB1.1 和 2.0 来说，这是默认的也是建议使用的机制）。

互斥的：
避免死锁；只有当在非群集的服务器上要求高度一致性时才使用它。

乐观的：
在事务期间， EJB 容器或数据库中不会保持锁定。但是 EJB 容器确保事务正在更新的数据没有被修改。

只读的：
事务结束时，容器不会试着保存 bean 的状态；对不会对永久性数据做任何修改的 EJB 使用这一点。借助只读策略，使用 <read-time-out-seconds> 使容器中缓存的 bean 数据变得无效；当出现超时时，这会更新永久性存储器中数据。

技巧

·   考虑执行线程的数目，以便配置自由池中 bean 的最大数目。

·   要限制有状态会话 EJB 使用的内存，需要设置能够驻留在缓存中的 bean 的最大数目 (max-beans-in-cache) 。

·   缓存过小会导致频繁的激活和钝化。

·   缓存过大会导致内存浪费。

·   当达到理想的超时时间长短之后， LRU 算法会让 bean 保持在钝化状态。

·   为了避免钝化有状态会话 EJB 所带来的相关开销，使用 Not Recently Used (NRU) 算法。

·   EJB 的本地接口提供对服务器端 EJB 客户端的最优访问。

·   联合缓存使管理员能够在 weblogic-application.xml 中只调整一块缓存，而不是多块缓存。

·   使用容器托管事务的消息驱动 bean 必须使用 XA 连接工厂。

安全性
永远不要对生产服务器使用开发模式；开发模式会放宽域中所有服务器的安全限制。使用兼容性安全性时，禁用生产中的客人登录，这样就可以使用客人登录来访问 WebLogic Server 中的 WebLogic 资源。
 
创建安全策略时，如果通过继承得到的策略语句出现在Policy Editor页面的Inherited Policy Statement框中，新的策略会覆盖它们。想要修改在J2EE部署描述符中定义的安全策略，需要进行重新部署；在管理控制台中修改内嵌的LDAP策略是动态的。把另外的管理用户配置为诸如admin、deployer、 monitor 或 operator这样的角色。
 
SerializedSystemIni.dat包含对域中密码进行处理以后得到的杂乱信息；确保您在安全的地方存储了这个文件的拷贝。只能授予WebLogic系统管理员帐号对SerializedSystemIni.dat的读权限。如果您丢失了管理密码，而且没有以boot.properties文件的形式保存启动身份，那么您不能重新启动服务器。

技巧

·   在 boot.properties 文件中保存对有权启动 WebLogic Server 的用户进行加密后的启动身份。

·   BEA 建议使用安全角色（而不是用户或组）来保护 WebLogic 资源；首先把用户指派给组，然后创建角色语句。

·   不要以 root 权限安装或运行 WebLogic Server 。如果您必须绑定到一个要求授权的端口，请在 WebLogic 机器配置中使用 post-bind UID 或 post-bind GID 。

·   设置 WebLogic 安装和应用程序目录的所有权，只允许运行服务器的用户帐户访问它们。

恢复管理员密码
使用默认的身份认证程序时，如果您尚未修改全局的管理角色（默认情况下被授给管理员组），您可以恢复 WebLogic 域中的管理员密码。
<span style="FONT-SIZE: 9pt; COLOR: black; F