From dna-commits at lists.jboss.org Tue Jun 9 20:29:26 2009 Content-Type: multipart/mixed; boundary="===============3640486313385546883==" MIME-Version: 1.0 From: dna-commits at lists.jboss.org To: dna-commits at lists.jboss.org Subject: [dna-commits] DNA SVN: r1025 - trunk/docs/reference/src/main/docbook/en-US/content/connectors. Date: Tue, 09 Jun 2009 20:18:55 -0400 Message-ID: --===============3640486313385546883== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: rhauch Date: 2009-06-09 20:18:54 -0400 (Tue, 09 Jun 2009) New Revision: 1025 Modified: trunk/docs/reference/src/main/docbook/en-US/content/connectors/federatio= n.xml Log: Added to the Reference Guide more detail about how the federated connector = can parallelize the fork-join processes. Also addressed the limitations of= update requests when such requests do not map to a single projection. Modified: trunk/docs/reference/src/main/docbook/en-US/content/connectors/fe= deration.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/reference/src/main/docbook/en-US/content/connectors/federati= on.xml 2009-06-09 23:57:54 UTC (rev 1024) +++ trunk/docs/reference/src/main/docbook/en-US/content/connectors/federati= on.xml 2009-06-10 00:18:54 UTC (rev 1025) @@ -358,8 +358,46 @@ composing the results. Technically, Step 2 performs the fork and join = operations, but this class uses &RequestProcessor; implementations to do Step 1 and 3 (called &ForkRequestProcessor; and = &JoinRequestProcessor;, respectively). + + Such fork-join style techniques are well-suited to parallel = processing. This connector uses an &ExecutorService; + to allow these different processors to operate concurrently. This can= greatly improve the performance as perceived + by the clients, since indeed much of the operations on the different s= ources are occurring at the same time. + + + It is also possible that not every incoming &Request; get projected to= all sources. Indeed, many operations can + effectively be mapped to a single projection. In= such cases, the overhead of the federated + connector is quite minimal. + + + + &Request;s that include the &Path; within the request's &Location; ca= n be very quickly mapped to the correct projection, + and thus such federated requests can be processed with very little ov= erhead. However, when requests contain &Location;s + that only contain identification properties (e.g., UUIDs), the connec= tor may not be able to determine the correct + projection(s), and may have to simply forward the request to all of t= he projections. This is obviously less desirable, + so when possible ensure that the &Request; objects include the &Path;. + + + Update operations + + The federated connector behavior for read-only re= quests is fairly obvious. In the best case, the connector determines the + appropriate projections, forwards the request into the appropriate sou= rces, and then combines the results. + But what happens with change requests? + + + Currently, the federated connector requires that each &ChangeRequest; = be mapped to one and only one projection. + However, when a single projection cannot be determined for a &ChangeRe= quest;, the connector throws an error. + + + This is thought to be a minimal problem that will not actually be an i= ssue in most uses of the federated connector. = + If you find that your usage does indeed fall into this category, = + please let us know via the mailing lis= ts or log + an enhancement request in JIRA. Be sure= to include as much detail as possible about the scenario, + the problem condition, and the desired behavior. + = + + Configuration The federated repository uses other &RepositorySource;s that are to be= federated and a &RepositorySource; that is to be used as the --===============3640486313385546883==--