语源科技BlogJava-This Is A FineDay

oracle批量fetch的sql语句 bulk collect into

Peter Pan — Tue, 22 Feb 2011 03:39:00 GMT

declare cursor c1 is select * from t_depart; type v_depart_type is table of t_depart%rowtype ; v_depart v_depart_type ; begin open c1; fetch c1 bulk collect into v_depart ; --limit batch_cnt; for i in 1..v_depart.count loop dbms_output.put_line(v_depart(i).depart_code||' '|| v_depart(i).depart_name); end loop; close c1; end;

Peter Pan 2011-02-22 11:39 发表评论

Understanding JTA

Peter Pan — Tue, 19 Oct 2010 11:49:00 GMT

http://archive.devx.com/java/free/articles/dd_jta/jta-2.asp Understanding JTA—the Java Transaction API (cont.) Distributed Transactions and the Transaction Manager As we stated previously, a distributed transaction is a transaction that accesses and updates data on two or more networked resources. These resources could consist of several different RDBMSs housed on a single sever, for example, Oracle, SQL Server, and Sybase; or they could include several instances of a single type of database residing on a number of different servers. In any case, a distributed transaction involves coordination among the various resource managers. This coordination is the function of the transaction manager. The transaction manager is responsible for making the final decision either to commit or rollback any distributed transaction. A commit decision should lead to a successful transaction; rollback leaves the data in the database unaltered. JTA specifies standard Java interfaces between the transaction manager and the other components in a distributed transaction: the application, the application server, and the resource managers. This relationship is illustrated in the following diagram: The numbered boxes around the transaction manager correspond to the three interface portions of JTA: 1—UserTransaction—The javax.transaction.UserTransaction interface provides the application the ability to control transaction boundaries programmatically. The javax.transaction.UserTransaction method starts a global transaction and associates the transaction with the calling thread. 2—Transaction Manager—The javax.transaction.TransactionManager interface allows the application server to control transaction boundaries on behalf of the application being managed. 3—XAResource—The javax.transaction.xa.XAResource interface is a Java mapping of the industry standard XA interface based on the X/Open CAE Specification (Distributed Transaction Processing: The XA Specification). Notice that a critical link is support of the XAResource interface by the JDBC driver. The JDBC driver must support both normal JDBC interactions, through the application and/or the application server, as well as the XAResource portion of JTA. Developers of code at the application level should not be concerned about the details of distributed transaction management. This is the job of the distributed transaction infrastructure—the application server, the transaction manager, and the JDBC driver. The only caveat for application code is that is should not invoke a method that would affect the boundaries of a transaction while the connection is in the scope of a distributed transaction. Specifically, an application should not call the Connection methods commit, rollback, and setAutoCommit(true) because they would interfere with the infrastructure's management of the distributed transaction. The Distributed Transaction Process The transaction manager is the primary component of the distributed transaction infrastructure; however, the JDBC driver and application server components should have the following characteristics: • The driver should implement the JDBC 2.0 API, including the Optional Package interfaces XADataSource and XAConnection, and the JTA interface XAResource. • The application server should provide a DataSource class that is implemented to interact with the distributed transaction infrastructure and a connection pooling module (for improved performance). The first step of the distributed transaction process is for the application to send a request for the transaction to the transaction manager. Although the final commit/rollback decision treats the transaction as a single logical unit, there can be many transaction branches involved. A transaction branch is associated with a request to each resource manager involved in the distributed transaction. Requests to three different RDBMSs, therefore, require three transaction branches. Each transaction branch must be committed or rolled back by the local resource manager. The transaction manager controls the boundaries of the transaction and is responsible for the final decision as to whether or not the total transaction should commit or rollback. This decision is made in two phases, called the Two-Phase Commit Protocol. In the first phase, the transaction manager polls all of the resource managers (RDBMSs) involved in the distributed transaction to see if each one is ready to commit. If a resource manager cannot commit, it responds negatively and rolls back its particular part of the transaction so that data is not altered. In the second phase, the transaction manager determines if any of the resource managers have responded negatively, and, if so, rolls back the whole transaction. If there are no negative responses, the translation manager commits the whole transaction, and returns the results to the application. Developers of transaction manager code must be conversant with all three interfaces of JTA: UserTransaction, TransactionManager, and XAResource, which are described in the Sun JTA specification. The JDBC API Tutorial and Reference, Second Edition is also a useful reference. JDBC driver developers need only be concerned with the XAResource interface. This interface is a Java mapping of the industry standard X/Open XA protocol that allows a resource manager to participate in a transaction. The component of the driver connected with the XAResource interface is responsible for "translating" between the transaction manager and the resource manager. The following section provides examples of XAResource calls. The JDBC Driver and XAResource To simplify the explanation of XAResource, these examples illustrate how an application would use JTA when there is no application server and transaction manager involved. Basically, the application in these examples is also acting as application server and transaction manager. Most enterprises use transaction managers and application servers because they manage distributed transactions much more efficiently than an application can. By following these examples, however, an application developer can test the robustness of JTA support in a JDBC driver. Some examples may not work for a particular database because of inherent problems associated with that database. Before using JTA, you must first implement an Xid class for identifying transactions (this would normally be done by the transaction manager). The Xid contains three elements: formatID, gtrid (global transaction ID), and bqual (branch qualifier ID). The formatID is usually zero, meaning that you are using the OSI CCR (Open Systems Interconnection Commitment, Concurrency, and Recovery standard) for naming. If you are using another format, the formatID should be greater than zero. A value of -1 means that the Xid is null. The gtrid and bqual can each contain up to 64 bytes of binary code to identify the global transaction and the branch transaction, respectively. The only requirement is that the gtrid and bqual taken together must be globally unique. Again, this can be achieved by using the naming rules specified in the OSI CCR. The following example illustrates implementation of an Xid: import javax.transaction.xa.*; public class MyXid implements Xid { protected int formatId; protected byte gtrid[]; protected byte bqual[]; public MyXid() { } public MyXid(int formatId, byte gtrid[], byte bqual[]) { this.formatId = formatId; this.gtrid = gtrid; this.bqual = bqual; } public int getFormatId() { return formatId; } public byte[] getBranchQualifier() { return bqual; } public byte[] getGlobalTransactionId() { return gtrid; } } Second, you need to create a datasource for the database that you are using: public DataSource getDataSource() throws SQLException { SQLServerDataSource xaDS = new com.merant.datadirect.jdbcx.sqlserver.SQLServerDataSource(); xaDS.setDataSourceName("SQLServer"); xaDS.setServerName("server"); xaDS.setPortNumber(1433); xaDS.setSelectMethod("cursor"); return xaDS; } Example 1—This example uses the two-phase commit protocol to commit one transaction branch: XADataSource xaDS; XAConnection xaCon; XAResource xaRes; Xid xid; Connection con; Statement stmt; int ret; xaDS = getDataSource(); xaCon = xaDS.getXAConnection("jdbc_user", "jdbc_password"); xaRes = xaCon.getXAResource(); con = xaCon.getConnection(); stmt = con.createStatement(); xid = new MyXid(100, new byte[]{0x01}, new byte[]{0x02}); try { xaRes.start(xid, XAResource.TMNOFLAGS); stmt.executeUpdate("insert into test_table values (100)"); xaRes.end(xid, XAResource.TMSUCCESS); ret = xaRes.prepare(xid); if (ret == XAResource.XA_OK) { xaRes.commit(xid, false); } } catch (XAException e) { e.printStackTrace(); } finally { stmt.close(); con.close(); xaCon.close(); } Because the initialization code is the same or very similar for all the examples, only significantly different code is represented from this point forward. Example 2—This example, similar to Example 1, illustrates a rollback: xaRes.start(xid, XAResource.TMNOFLAGS); stmt.executeUpdate("insert into test_table values (100)"); xaRes.end(xid, XAResource.TMSUCCESS); ret = xaRes.prepare(xid); if (ret == XAResource.XA_OK) { xaRes.rollback(xid); } Example 3—This example shows how a distributed transaction branch suspends, lets the same connection do a local transaction, and them resumes the branch later. The two-phase commit actions of distributed transaction do not affect the local transaction. xid = new MyXid(100, new byte[]{0x01}, new byte[]{0x02}); xaRes.start(xid, XAResource.TMNOFLAGS); stmt.executeUpdate("insert into test_table values (100)"); xaRes.end(xid, XAResource.TMSUSPEND); // This update is done outside of transaction scope, so it // is not affected by the XA rollback. stmt.executeUpdate("insert into test_table2 values (111)"); xaRes.start(xid, XAResource.TMRESUME); stmt.executeUpdate("insert into test_table values (200)"); xaRes.end(xid, XAResource.TMSUCCESS); ret = xaRes.prepare(xid); if (ret == XAResource.XA_OK) { xaRes.rollback(xid); } Example 4—This example illustrates how one XA resource can be shared among different transactions. Two transaction branches are created, but they do not belong to the same distributed transaction. JTA allows the XA resource to do a two-phase commit on the first branch even though the resource is still associated with the second branch. xid1 = new MyXid(100, new byte[]{0x01}, new byte[]{0x02}); xid2 = new MyXid(100, new byte[]{0x11}, new byte[]{0x22}); xaRes.start(xid1, XAResource.TMNOFLAGS); stmt.executeUpdate("insert into test_table1 values (100)"); xaRes.end(xid1, XAResource.TMSUCCESS); xaRes.start(xid2, XAResource.TMNOFLAGS); // Should allow XA resource to do two-phase commit on // transaction 1 while associated to transaction 2 ret = xaRes.prepare(xid1); if (ret == XAResource.XA_OK) { xaRes.commit(xid2, false); } stmt.executeUpdate("insert into test_table2 values (200)"); xaRes.end(xid2, XAResource.TMSUCCESS); ret = xaRes.prepare(xid2); if (ret == XAResource.XA_OK) { xaRes.rollback(xid2); } Example 5—This example illustrates how transaction branches on different connections can be joined as a single branch if they are connected to the same resource manager. This feature improves distributed transaction efficiency because it reduces the number of two-phase commit processes. Two XA connections to the same database server are created. Each connection creates its own XA resource, regular JDBC connection, and statement. Before the second XA resource starts a transaction branch, it checks to see if it uses the same resource manager as the first XA resource uses. If this is case, as in this example, it joins the first branch created on the first XA connection instead of creating a new branch. Later, the transaction branch can be prepared and committed using either XA resource. xaDS = getDataSource(); xaCon1 = xaDS.getXAConnection("jdbc_user", "jdbc_password"); xaRes1 = xaCon1.getXAResource(); con1 = xaCon1.getConnection(); stmt1 = con1.createStatement(); xid1 = new MyXid(100, new byte[]{0x01}, new byte[]{0x02}); xaRes1.start(xid1, XAResource.TMNOFLAGS); stmt1.executeUpdate("insert into test_table1 values (100)"); xaRes1.end(xid, XAResource.TMSUCCESS); xaCon2 = xaDS.getXAConnection("jdbc_user", "jdbc_password"); xaRes2 = xaCon1.getXAResource(); con2 = xaCon1.getConnection(); stmt2 = con1.createStatement(); if (xaRes2.isSameRM(xaRes1)) { xaRes2.start(xid1, XAResource.TMJOIN); stmt2.executeUpdate("insert into test_table2 values (100)"); xaRes2.end(xid1, XAResource.TMSUCCESS); } else { xid2 = new MyXid(100, new byte[]{0x01}, new byte[]{0x03}); xaRes2.start(xid2, XAResource.TMNOFLAGS); stmt2.executeUpdate("insert into test_table2 values (100)"); xaRes2.end(xid2, XAResource.TMSUCCESS); ret = xaRes2.prepare(xid2); if (ret == XAResource.XA_OK) { xaRes2.commit(xid2, false); } } ret = xaRes1.prepare(xid1); if (ret == XAResource.XA_OK) { xaRes1.commit(xid1, false); } Example 6—This example shows how to recover prepared or heuristically completed transaction branches during failure recovery. It first tries to rollback each branch; if it fails, it tries to tell resource manager to discard knowledge about the transaction. MyXid[] xids; xids = xaRes.recover(XAResource.TMSTARTRSCAN | XAResource.TMENDRSCAN); for (int i=0; xids!=null && i

Peter Pan 2010-10-19 19:49 发表评论

oracle实现Tree(2)

Peter Pan — Wed, 13 Oct 2010 04:38:00 GMT

select SYS_CONNECT_BY_PATH(no, '/'), level, CONNECT_BY_ISLEAF, CONNECT_BY_ROOT no, cr.* from cr where level >2 start with cr.parent_no is null connect by NOCYCLE prior cr.no = cr.parent_no1

Peter Pan 2010-10-13 12:38 发表评论

ORACLE shared server与dedicated server

Peter Pan — Wed, 03 Feb 2010 05:48:00 GMT

Oracle Dedicated server . 用户进程和服务器进程是分开的。 . 每个用户进程都有自己的服务器进程。 . 用户进程和服务器进程可在不同的机器上运行，以利用分布式处理的优势。 . 用户进程和服务器进程的比率是1 比1。 . 即使用户进程不发出数据库请求，专用服务器也存在，只是保持空闲状态。此处所用的程序接口取决于用户进程和专用服务器进程是否在同一台机器上。如果在同一机器上，进程间的程序接口将使用主机操作系统的交互进程通信(IPC) 机制。 Oracle Shared Server . 在Oracle Shared Server 体系结构下，客户机-用户进程最终会与调度程序建立连接。 . PMON 进程向监听程序注册调度程序的位置和负载，使监听程序能够将请求转发给占用率最低的调度程序。服务注册不要求在listener.ora 文件中进行配置。 . 一个调度程序可同时支持多个客户机连接。每个客户机连接都使用一个虚拟线路。虚拟线路是一块共享内存，调度程序将它用于客户机数据库连接请求与答复。 scott@ORCL> show parameter shared_server NAME TYPE VALUE ------------------------------------ ----------- -------------------- max_shared_servers integer shared_server_sessions integer shared_servers integer 1 shared_servers大于0即支持共享服务器连接 scott@ORCL> show parameter dispatchers NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ dispatchers string (PROTOCOL=TCP) (SERVICE=orclXDB) ORCL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = orcl) (SERVER =DEDICATED) ) ) ORCL1 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = orclXDB) (SERVER =SHARED) ) )

Peter Pan 2010-02-03 13:48 发表评论

独家：程序员五大层次，你属于哪一层？(转)

Peter Pan — Wed, 10 Jun 2009 03:40:00 GMT

(转)http://news.csdn.net/a/20090610/211855.html 软件界一个无可争议的事实是，不同程序员的效率有差别，而且差别很大。许多专家将优秀程序员和一般程序员区分地很清楚。大多数研究得出结论认为，一般程序员跟优秀程序员之间在工作效率和质量上存在10：1的关系：优秀程序员和水平较差的程序员的编码时间比例为 1：20；debugging时间比为1：25；代码数量比是5：1；程序执行速度比例是10：1。而且发现，程序员的代码质量和效率跟工作经验没有关系。让我们看看一些软件大腕们是如何看待优秀程序员和一般程序员的： Randall E. Stross：无论是从软件标准、创造性、开发速度、还是设计思路或者解决问题的能力上来说，优秀程序员比差的程序员都何止好一点。 Bill Gates：一个优秀的机床工值一个一般机床工的好几倍，而一个优秀程序员值一个一般程序员的10000倍。 Robert C. Martin：90%的代码是由10%的程序员写出来的。就我个人从事编程行业25年、从事过六家软件公司的经历来看，10：1这个定律千真万确。基于这一定律以及程序员工作效率的差别，程序员因此被分为五大类： 1. 大师级程序员（Visionary/Artist Programmer）大师级程序员是软件界绝对的稀有种族，他们可以创造出99.9%的程序员所创造不出来的东西。他们发明新的应用和软件模式来驱动软件产业的发展。 Napster, Netscape以及World Wide Web都是大师级程序员创造的。对他们而言，软件更多的是艺术而非科学。在这个级别，速度和质量不是最重要的，他们创造出的财富才是最重要的。许多开发团队或者公司顶多也就一个大师级程序员，通常是这个公司的技术创始人或者CTO。 2. 开拓者程序员（Trailblazer Programmer）开拓者程序员通常带来很好的主意和趋势。他们通常是最终产品的原型创作者，他们一天做出的事情大部分程序员需要几周甚至几个月。开拓者程序员总是在尝试新工具、新技术，不断地学习和搜寻方法来提高工作效率，并通常是其他程序员的导师和老师，而且你经常会发现当其他程序员早已离开的时候他们却依然工作到深夜。尽管这样级别的程序员工资很高，但是每个成功的公司或团队还是应该配备一两个开拓者程序员。 3.骨干程序员（ Workhorse Programmer）骨干程序员是一个公司或者开发团队的脊柱，这些人尽管不是很有创新性，但往往比较高效且值得信赖。给一位骨干程序员一套模板和合适的工具，他们总能以最短的时间交出错误最少的代码。 4.机械程序员（ Drone Programmer）许多程序员就是朝九晚五地为了填塞下自己钱包的机械程序员。他们不愿意接触新技术、避免学习新事物。许多公司或者开发团队都有许多这样的机械程序员，因为他们很便宜，但岂不知更贵的程序员才真正地更便宜。 5.白痴程序员（ Idiot Programmer）林子大了什么鸟都有，软件领域也不例外。编程需要抽象和逻辑思维，然而一些尚不具备此能力者由于向往着不错的薪水而加入了该领域。白痴程序员总是对最简单的算法也搞不清楚，他们总是错过软件截止日期，终日无所获。白痴程序员最好的出路就是换行。（王玉磊/译）

Peter Pan 2009-06-10 11:40 发表评论

Flex 父子窗口通信的问题收藏

Peter Pan — Fri, 20 Feb 2009 06:22:00 GMT

假设有父窗体P，在父窗体中弹出子窗体C,进行必要的操作后，返回父窗体。
1、弹出子窗体
var c:ChildForm = new ChildForm (); // 新建子窗体对象
PopUpManager.addPopUp(c, this, true); // 将子窗体加入PopUpManager中
c.studentId = ""; // 向子窗体传递参数
c.callbackFunction = this.refresh; // 子窗体中可以调用的父窗体函数（这里是子窗体关闭时，用来刷新父窗体的内容
PopUpManager.centerPopUp(c); // 子窗体弹出，居中
2、子窗体关闭时，调用父窗体
public var callbackFunction:Function; //回调函数
public var studentId:String = "";
public function doClose():void {
PopUpManager.removePopUp(this);
if (isUpdate) { callbackFunction.call(parent); // 调用父窗体的刷新函数
}
}

Peter Pan 2009-02-20 14:22 发表评论

flex Repeater click收藏

Peter Pan — Fri, 20 Feb 2009 06:20:00 GMT

                            showNewWindow(event.currentTarget.getRepeaterItem().id);"
                                      mouseOut="labelMouseOut(event);" mouseOver="labelMouseOver(event);"/>

Peter Pan 2009-02-20 14:20 发表评论

flex sdk 3.2 RemoteObject问题

Peter Pan — Fri, 20 Feb 2009 02:47:00 GMT

TypeError: Error #1034: 强制转换类型失败:无法将Object@3b3a1a1转换为 mx.messaging.messages.IMessage。

需要在Application里面增加
import flash.net.registerClassAlias;
import mx.messaging.messages.RemotingMessage;

registerClassAlias("flex.messaging.messages.RemotingMessage", RemotingMessage);

Peter Pan 2009-02-20 10:47 发表评论

Repeater remote 嵌套

Peter Pan — Thu, 15 Jan 2009 03:20:00 GMT

Repeater remote object 嵌套似乎又是flex的一个Bug，郁闷了一天
最终解决方法用Script初始化数据

<mx:Label text="{new2.currentItem.@label2}" /> OK
<mx:Label text="{ppt.currentItem.typeName}" /> NOK
<mx:Label text="{ppt.currentItem.typeName}" creationComplete="accChildCreationComplete(event);" width="100%"/> OK

1<mx:XMLListCollection id="xmlListColl">
2        <mx:source>
3            <mx:XMLList>
4                <node label="One">
5                    <node2 label2="One.1" />
6                    <node2 label2="One.2" />
7                    <node2 label2="One.3" />
8                node>
9                <node label="Two">
10                    <node2 label2="Two.1" />
11                    <node2 label2="Two.2" />
12                    <node2 label2="Two.3" />
13                node>
14            mx:XMLList>
15        mx:source>
16    mx:XMLListCollection>
17    <mx:Accordion id="accoridLeft"
18                  resizeToContent="true"
19                  width="100%">
20           <mx:Repeater id="news" dataProvider="{xmlListColl}">
21            <mx:VBox label="{news.currentItem.@label}">
22                <mx:VDividedBox horizontalAlign="left" paddingLeft="15">
23                         <mx:Repeater id="new2" dataProvider="{news.currentItem.node2}">
24                        <mx:VBox label="{new2.currentItem.@label2}">
25                            <mx:Label text="{new2.currentItem.@label2}" click="onClick1(event);"/>
26                        mx:VBox>
27                     mx:Repeater>
28                mx:VDividedBox>
29            mx:VBox>
30        mx:Repeater>
31    mx:Accordion>

    <mx:Script>

        import mx.rpc.events.ResultEvent;
        import mx.events.FlexEvent;
        import mx.utils.ArrayUtil;
        import mx.collections.ArrayList;
        import mx.collections.ArrayCollection;
        import mx.controls.Alert;
        import mx.effects.easing.*;

        public function init():void {
            pts.getProductTypeMenu();
        }

        public function accChildCreationComplete(event:FlexEvent):void{
            event.target.text = String(event.currentTarget.getRepeaterItem().typeName);
        }

        ]]>
    mx:Script>
    <mx:RemoteObject id="pts" destination="productTypeService">
    mx:RemoteObject>
    <mx:Accordion id="accoridLeft"
                  resizeToContent="true"
                  width="100%">
        <mx:Repeater dataProvider="{pts.getProductTypeMenu.lastResult}" id="pt">
            <mx:VBox label="{pt.currentItem.typeName}" width="100%">
                <mx:Repeater dataProvider="{pt.currentItem.productTypes}" id="ppt">
                    <mx:Label text="{ppt.currentItem.typeName}" creationComplete="accChildCreationComplete(event);" width="100%"/>
                mx:Repeater>
            mx:VBox>
        mx:Repeater>
    mx:Accordion>

Peter Pan 2009-01-15 11:20 发表评论

cannot convert mx.managers::HistoryManagerImpl@2403de71 to mx.managers.IHistoryManager.

Peter Pan — Sun, 04 Jan 2009 08:35:00 GMT

又一个flex bug汗了半天

Actual Results:
TypeError: Error #1034: Type Coercion failed: cannot convert mx.managers::HistoryManagerImpl@2403de71 to mx.managers.IHistoryManager.
at mx.managers::HistoryManager$/get impl()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\managers\HistoryManager.as:96]
at mx.managers::HistoryManager$/unregister()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\managers\HistoryManager.as:144]
at mx.containers::ViewStack/commitProperties()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\containers\ViewStack.as:651]
at mx.containers::TabNavigator/commitProperties()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\containers\TabNavigator.as:504]
at mx.core::UIComponent/validateProperties()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:5670]
at mx.managers::LayoutManager/validateProperties()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\managers\LayoutManager.as:519]
at mx.managers::LayoutManager/doPhasedInstantiation()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\managers\LayoutManager.as:639]
at Function/http://adobe.com/AS3/2006/builtin::apply()
at mx.core::UIComponent/callLaterDispatcher2()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:8460]
at mx.core::UIComponent/callLaterDispatcher()[E:\dev\3.0.x\frameworks\projects\framework\src\mx\core\UIComponent.as:8403]

Adding the following code to your main app may resolve the problem. It did for me:

import mx.managers.HistoryManager;
private var hist:HistoryManager;

See:

https://bugs.adobe.com/jira/browse/SDK-13121
http://bugs.adobe.com/jira/browse/SDK-12218

I'm not sure that I agree that it's "Not a Bug" (see Resolution of SDK-12218). I would hardly classify the code given by Rodrigo as unusual or buggy. If the default behaviour of modules is to share managers with the main app (if I understand the problem correctly), then they should be able to clean up after themselves during the unload process gracefully.

Peter Pan 2009-01-04 16:35 发表评论