|
Home > Archive > Apache JDO Project > November 2007 > multiple databases one PM/TX
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
multiple databases one PM/TX
|
|
| Erik Bengtson 2007-10-26, 1:11 pm |
| In JPOX we are implementing the access to multiple datastores within a single
PM/TX. If not too late, I’m wonder if you like to hear a proposal to
standardize the configuration of the “jdoconfig” and jdo metadata to be able to
handle this scenario. It may sound overkill, but IMO is a major advance over
JPA.
To introduce the subject, the goal is to handle persistence in multiple
databases (e.g. derby, oracle, DB4O, Versant, XML) within a single JDO
transaction/ single PM. From the user point of view, there are two items that
must be configured, jdo metadata, jdo configuration, in which would be part of
this proposal, so I show below an example of the configurations:
/jdoconfig/ sequence unbounded PMF
/jdoconfig/ sequence unbounded Resource
/PMF/
/PMF/@Class
/PMF/@TransactionTimeout
/PMF/@...
/Resource/
/Resource/@Name
/Resource/Connection Settings/
/Resource/Connection Settings/@ConnectionFactoryName
/Resource/Connection Settings/@ConnectionClientID
/Resource/Connection Settings/@ReadOnly
/Resource/Connection Settings/@...
/Resource/Transaction/
/Resource/Transaction/@TwoPhaseCommit
/Resource/Transaction/@Timeout
ConnectionClientID
----------------------------
ConnectionClientID is the identifier for the connection. Some databases such as
Oracle use this to identify the end user (not the connection user).
ConnectionClientID would accept the values:
1 - CredentialMapping - the CredentialMapping takes the principal of the running
application and sets it as client id - eg. ConnectionClientID=CredentialMapping
2 - Identity – the client id is taken from the id right after the Identity word
- eg. ConnectionClientID=Identity:MyUser
ReadOnly
----------------------------
ReadOnly (accepts true, false) will block write operations to this connection
TwoPhaseCommit
--------------------------
Two options:
1 – LastLoggingResource - If the resource is non XA, push down this resource in
commit order.
2 – Emulated – Emulates non XA protocol. Heuristics errors could happen
Example:
<jdoconfig>
<pmf name=”snowdog” default-resource=”Oracle”>
</pmf>
<resource name=”ERP”>
<connection connectionfactoryname=”BSCS_Hot”/>
</resource>
<resource name=”PeopleSoft”>
<connection connectionfactoryname=”PS_Onyx”/>
</resource>
<resource name=”Oracle”>
<connection connectionfactoryname=”ORA_Vinci”
connection-client-id=”CredentialMapping”/>
<transaction two-phase-commit=”LLR” timeout=”30”/>
</resource>
<resource name=”Xml”>
<connection readonly=”true”/>
<extension>
<jpox:xml file=”file:/usr/home/myxml.xml”/>
</extension>
</resource>
</jdoconfig>
<jdo>
<package>
<class name=”Invoice” resource=”ERP”/>
<class name=”ClassData”/> <!-- uses default-resource -->
<class name=”Person” resource=”PeopleSoft”/>
<class name=”ReferenceData” resource=”Xml”/>
</package>
</jdo>
Quoting Michelle Caisse <Michelle.Caisse@sun.com>:
> Hi,
>
> We will have our regular meeting Friday, October 26 at 9 am PDT to
> discuss JDO TCK issues and status.
>
> Dial-in numbers are:
> 866 230-6968 294-0479#
> International: +1 865 544-7856
>
> Agenda:
>
> 1. Subquery spec update
> 2. Other issues
>
> Action Items from weeks past:
>
> [Oct 12 2007] AI Michael take a look at subquery tck tests.
> https://issues.apache.org/jira/browse/JDO-446
>
> [Sep 14 2007] AI Matthew provide examples for 8.6.1.1 jdoconfig.xml.
>
> [June 22 2007] AI Craig discuss svn:eol-style on email.
>
> [June 22 2007] AI Craig write a proposal on annotation overrides for
> the expert group.
>
> [May 25 2007] AI everyone Download the Grails demo from grails.org and
> check it out. Also look at Grails/Groovy ExpandoMetaClass that has the
> magic to avoid reflection and enhancement.
>
> [May 25 2007] AI Matthew Adams prepare a proposal with just the basics
> of schema synchronization with jdo and orm metadata.
>
> [May 18 2007] AI Craig update http://wiki.apache.org/jdo/
> CurrentDevelopment wiki page
>
> [Apr 27 2007] AI Craig review Query API and send email to experts.
>
> [Apr 27 2007] AI Erik file a JIRA regarding JPA style transactions and
> attach his discussion document to it.
>
> [Mar 9 2007] AI Craig: Update the spec to require that the key of the
> listener is the class name of the listener, for consistency with
> proposed xml..
>
> [Mar 2 2007] AI Craig: update the JDOHelper class to include a string
> constant "META-INF/jdo.xml" and a new method
> getPersistenceManagerFactory taking no arguments.
>
> [Aug 11 2006] AI Craig propose some semantics for behavior if user
> tries to add to a list where the ordering element is incorrect.
>
> [Jul 14 2006] AI: Erik document 220 annotations that don't have a
> corresponding JDO concept.
>
> [Jun 23 2006] AI Martin look at what Hibernate and TopLink support
> for Enum types. In progress.
>
> [Apr 14 2006] AI Craig: update the roadmap for JDO. In progress.
>
> [Nov 4 2005] AI Martin: Update Martin's wiki with discusion of JDK 1.5
> issues. In progress
>
> [Sep 2 2005] AI: To recruit members, update the web site. Articles on
> TheServerSide directing attention to the site. T-shirts, logo. AI:
> Craig write a ServerSide article.
>
> -- Michelle
>
>
| |
| Eric Samson 2007-10-29, 1:11 pm |
| Hello Erik,
Once again you start an important topic here! :-)
We also are working on a multi-data sources PMF.
I think the name "resource" could be confusing (I tend to prefer "data source").
Maybe the data source properties should be defined elsewhere (as you can have quite complex configurations when you want to access non-relational data stores)?
Best Regards,
.....: Eric Samson, Founder & CTO, Xcalia
Service your Data!
-----Message d'origine-----
De : Erik Bengtson [mailto:erik@jpox.org]
Envoyé : vendredi 26 octobre 2007 15:49
Ŕ : jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : multiple databases one PM/TX
In JPOX we are implementing the access to multiple datastores within a single
PM/TX. If not too late, I'm wonder if you like to hear a proposal to
standardize the configuration of the "jdoconfig" and jdo metadata to be able to
handle this scenario. It may sound overkill, but IMO is a major advance over
JPA.
To introduce the subject, the goal is to handle persistence in multiple
databases (e.g. derby, oracle, DB4O, Versant, XML) within a single JDO
transaction/ single PM. From the user point of view, there are two items that
must be configured, jdo metadata, jdo configuration, in which would be part of
this proposal, so I show below an example of the configurations:
/jdoconfig/ sequence unbounded PMF
/jdoconfig/ sequence unbounded Resource
/PMF/
/PMF/@Class
/PMF/@TransactionTimeout
/PMF/@...
/Resource/
/Resource/@Name
/Resource/Connection Settings/
/Resource/Connection Settings/@ConnectionFactoryName
/Resource/Connection Settings/@ConnectionClientID
/Resource/Connection Settings/@ReadOnly
/Resource/Connection Settings/@...
/Resource/Transaction/
/Resource/Transaction/@TwoPhaseCommit
/Resource/Transaction/@Timeout
ConnectionClientID
----------------------------
ConnectionClientID is the identifier for the connection. Some databases such as
Oracle use this to identify the end user (not the connection user).
ConnectionClientID would accept the values:
1 - CredentialMapping - the CredentialMapping takes the principal of the running
application and sets it as client id - eg. ConnectionClientID=CredentialMapping
2 - Identity - the client id is taken from the id right after the Identity word
- eg. ConnectionClientID=Identity:MyUser
ReadOnly
----------------------------
ReadOnly (accepts true, false) will block write operations to this connection
TwoPhaseCommit
--------------------------
Two options:
1 - LastLoggingResource - If the resource is non XA, push down this resource in
commit order.
2 - Emulated - Emulates non XA protocol. Heuristics errors could happen
Example:
<jdoconfig>
<pmf name="snowdog" default-resource="Oracle">
</pmf>
<resource name="ERP">
<connection connectionfactoryname="BSCS_Hot"/>
</resource>
<resource name="PeopleSoft">
<connection connectionfactoryname="PS_Onyx"/>
</resource>
<resource name="Oracle">
<connection connectionfactoryname="ORA_Vinci"
connection-client-id="CredentialMapping"/>
<transaction two-phase-commit="LLR" timeout="30"/>
</resource>
<resource name="Xml">
<connection readonly="true"/>
<extension>
<jpox:xml file="file:/usr/home/myxml.xml"/>
</extension>
</resource>
</jdoconfig>
<jdo>
<package>
<class name="Invoice" resource="ERP"/>
<class name="ClassData"/> <!-- uses default-resource -->
<class name="Person" resource="PeopleSoft"/>
<class name="ReferenceData" resource="Xml"/>
</package>
</jdo>
Quoting Michelle Caisse <Michelle.Caisse@sun.com>:
> Hi,
>
> We will have our regular meeting Friday, October 26 at 9 am PDT to
> discuss JDO TCK issues and status.
>
> Dial-in numbers are:
> 866 230-6968 294-0479#
> International: +1 865 544-7856
>
> Agenda:
>
> 1. Subquery spec update
> 2. Other issues
>
> Action Items from weeks past:
>
> [Oct 12 2007] AI Michael take a look at subquery tck tests.
> https://issues.apache.org/jira/browse/JDO-446
>
> [Sep 14 2007] AI Matthew provide examples for 8.6.1.1 jdoconfig.xml.
>
> [June 22 2007] AI Craig discuss svn:eol-style on email.
>
> [June 22 2007] AI Craig write a proposal on annotation overrides for
> the expert group.
>
> [May 25 2007] AI everyone Download the Grails demo from grails.org and
> check it out. Also look at Grails/Groovy ExpandoMetaClass that has the
> magic to avoid reflection and enhancement.
>
> [May 25 2007] AI Matthew Adams prepare a proposal with just the basics
> of schema synchronization with jdo and orm metadata.
>
> [May 18 2007] AI Craig update http://wiki.apache.org/jdo/
> CurrentDevelopment wiki page
>
> [Apr 27 2007] AI Craig review Query API and send email to experts.
>
> [Apr 27 2007] AI Erik file a JIRA regarding JPA style transactions and
> attach his discussion document to it.
>
> [Mar 9 2007] AI Craig: Update the spec to require that the key of the
> listener is the class name of the listener, for consistency with
> proposed xml..
>
> [Mar 2 2007] AI Craig: update the JDOHelper class to include a string
> constant "META-INF/jdo.xml" and a new method
> getPersistenceManagerFactory taking no arguments.
>
> [Aug 11 2006] AI Craig propose some semantics for behavior if user
> tries to add to a list where the ordering element is incorrect.
>
> [Jul 14 2006] AI: Erik document 220 annotations that don't have a
> corresponding JDO concept.
>
> [Jun 23 2006] AI Martin look at what Hibernate and TopLink support
> for Enum types. In progress.
>
> [Apr 14 2006] AI Craig: update the roadmap for JDO. In progress.
>
> [Nov 4 2005] AI Martin: Update Martin's wiki with discusion of JDK 1.5
> issues. In progress
>
> [Sep 2 2005] AI: To recruit members, update the web site. Articles on
> TheServerSide directing attention to the site. T-shirts, logo. AI:
> Craig write a ServerSide article.
>
> -- Michelle
>
[vbcol=seagreen]
>
| |
| Matthew Adams 2007-10-29, 7:11 pm |
| Hi all,
I like that JDO allows implementations to support this, and I do feel
that this could be a differentiator from JPA. The things that come
to my mind are the following:
* this should be an optional feature so that we don't slow down
implementations from being compliant
* we should examine the proposed JDO 2.1 metadata formats to ensure
that it can support but not require multiple data sources
* we need to examine the impact of configuring multiple data sources
on the API (i.e., new method JDOHelper.getPersistenceManagerFactory
(String... names), PersistenceManager#getDataStoreConnectio
n() &
JDOConnection#getNativeConnection?)
* configuration of JTA and the coordination of transactions across
all data sources
* this would slow down work on 2.1 -- can we add in another
maintenance release?
-matthew
On Oct 29, 2007, at 10:05 AM, Eric Samson wrote:
> Hello Erik,
>
>
>
> Once again you start an important topic here! :-)
>
>
>
> We also are working on a multi-data sources PMF.
>
>
>
> I think the name "resource" could be confusing (I tend to prefer
> "data source").
>
>
>
> Maybe the data source properties should be defined elsewhere (as
> you can have quite complex configurations when you want to access
> non-relational data stores)?
>
>
>
> Best Regards,
>
> ....: Eric Samson, Founder & CTO, Xcalia
>
> Service your Data!
>
>
>
> -----Message d'origine-----
> De : Erik Bengtson [mailto:erik@jpox.org]
> Envoyé : vendredi 26 octobre 2007 15:49
> Ŕ : jdo-dev@db.apache.org; jdo-experts-ext@sun.com
> Objet : multiple databases one PM/TX
>
>
>
> In JPOX we are implementing the access to multiple datastores
> within a single
>
> PM/TX. If not too late, I’m wonder if you like to hear a proposal to
>
> standardize the configuration of the “jdoconfig” and jdo metadata
> to be able to
>
> handle this scenario. It may sound overkill, but IMO is a major
> advance over
>
> JPA.
>
>
>
> To introduce the subject, the goal is to handle persistence in
> multiple
>
> databases (e.g. derby, oracle, DB4O, Versant, XML) within a single JDO
>
> transaction/ single PM. From the user point of view, there are two
> items that
>
> must be configured, jdo metadata, jdo configuration, in which would
> be part of
>
> this proposal, so I show below an example of the configurations:
>
>
>
> /jdoconfig/ sequence unbounded PMF
>
> /jdoconfig/ sequence unbounded Resource
>
>
>
> /PMF/
>
> /PMF/@Class
>
> /PMF/@TransactionTimeout
>
> /PMF/@...
>
> /Resource/
>
> /Resource/@Name
>
> /Resource/Connection Settings/
>
> /Resource/Connection Settings/@ConnectionFactoryName
>
> /Resource/Connection Settings/@ConnectionClientID
>
> /Resource/Connection Settings/@ReadOnly
>
> /Resource/Connection Settings/@...
>
> /Resource/Transaction/
>
> /Resource/Transaction/@TwoPhaseCommit
>
> /Resource/Transaction/@Timeout
>
>
>
> ConnectionClientID
>
> ----------------------------
>
> ConnectionClientID is the identifier for the connection. Some
> databases such as
>
> Oracle use this to identify the end user (not the connection user).
>
> ConnectionClientID would accept the values:
>
>
>
> 1 - CredentialMapping - the CredentialMapping takes the principal
> of the running
>
> application and sets it as client id - eg.
> ConnectionClientID=CredentialMapping
>
> 2 - Identity – the client id is taken from the id right after the
> Identity word
>
> - eg. ConnectionClientID=Identity:MyUser
>
>
>
> ReadOnly
>
> ----------------------------
>
> ReadOnly (accepts true, false) will block write operations to this
> connection
>
>
>
> TwoPhaseCommit
>
> --------------------------
>
> Two options:
>
>
>
> 1 – LastLoggingResource - If the resource is non XA, push down this
> resource in
>
> commit order.
>
> 2 – Emulated – Emulates non XA protocol. Heuristics errors could
> happen
>
>
>
> Example:
>
>
>
> <jdoconfig>
>
>
>
> <pmf name=”snowdog” default-resource=”Oracle”>
>
> </pmf>
>
>
>
> <resource name=”ERP”>
>
> <connection connectionfactoryname=”BSCS_Hot”/>
>
> </resource>
>
>
>
> <resource name=”PeopleSoft”>
>
> <connection connectionfactoryname=”PS_Onyx”/>
>
> </resource>
>
>
>
> <resource name=”Oracle”>
>
> <connection connectionfactoryname=”ORA_Vinci”
>
> connection-client-id=”CredentialMapping”/>
>
> <transaction two-phase-commit=”LLR” timeout=”30”/>
>
> </resource>
>
>
>
> <resource name=”Xml”>
>
> <connection readonly=”true”/>
>
> <extension>
>
> <jpox:xml file=”file:/usr/home/myxml.xml”/>
>
> </extension>
>
> </resource>
>
>
>
>
>
> </jdoconfig>
>
>
>
> <jdo>
>
> <package>
>
> <class name=”Invoice” resource=”ERP”/>
>
> <class name=”ClassData”/> <!-- uses default-resource -->
>
> <class name=”Person” resource=”PeopleSoft”/>
>
> <class name=”ReferenceData” resource=”Xml”/>
>
> </package>
>
> </jdo>
>
>
>
>
>
>
>
>
>
> Quoting Michelle Caisse <Michelle.Caisse@sun.com>:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> grails.org and
>
> has the
>
>
>
> basics
>
>
>
>
>
>
>
>
> transactions and
>
>
>
> the
>
>
>
>
> string
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> JDK 1.5
>
>
>
> Articles on
>
> AI:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
| |
| Eric Samson 2007-10-30, 1:11 pm |
| Hey Matthew,
See my comments inline.
Rgds,
.....: Eric Samson, Founder & CTO, xcalia
Service your Data!
De : Matthew Adams [mailto:matthew@matthewadams.org]
Envoyé : lundi 29 octobre 2007 20:25
Ŕ : Eric Samson
Cc : Erik Bengtson; jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : Re: multiple databases one PM/TX
Hi all,
I like that JDO allows implementations to support this, and I do feel that this could be a differentiator from JPA. The things that come to my mind are the following:
* this should be an optional feature so that we don't slow down implementations from being compliant
* we should examine the proposed JDO 2.1 metadata formats to ensure that it can support but not require multiple data sources
[Eric Samson] Agreed.
* we need to examine the impact of configuring multiple data sources on the API (i.e., new method JDOHelper.getPersistenceManagerFactory(String... names), PersistenceManager#getDataStoreConnectio
n() & JDOConnection#getNativeConnection?)
[Eric Samson] IMHO, this is more for the sake of completion rather than a real need, but why not.
* configuration of JTA and the coordination of transactions across all data sources
[Eric Samson] Do you want to configure distributed transactions or do you want the implementation to decide how to (transparently ?) manage them? BTW: what kind of configuration do you have in mind? Is that JTA only? What about WS-*? Or a mix of them? Or something else?
* this would slow down work on 2.1 -- can we add in another maintenance release?
[Eric Samson] Yes, should be later in time.
-matthew
On Oct 29, 2007, at 10:05 AM, Eric Samson wrote:
Hello Erik,
Once again you start an important topic here! :-)
We also are working on a multi-data sources PMF.
I think the name "resource" could be confusing (I tend to prefer "data source").
Maybe the data source properties should be defined elsewhere (as you can have quite complex configurations when you want to access non-relational data stores)?
Best Regards,
.....: Eric Samson, Founder & CTO, Xcalia
Service your Data!
-----Message d'origine-----
De : Erik Bengtson [mailto:erik@jpox.org]
Envoyé : vendredi 26 octobre 2007 15:49
Ŕ : jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : multiple databases one PM/TX
In JPOX we are implementing the access to multiple datastores within a single
PM/TX. If not too late, I'm wonder if you like to hear a proposal to
standardize the configuration of the "jdoconfig" and jdo metadata to be able to
handle this scenario. It may sound overkill, but IMO is a major advance over
JPA.
To introduce the subject, the goal is to handle persistence in multiple
databases (e.g. derby, oracle, DB4O, Versant, XML) within a single JDO
transaction/ single PM. From the user point of view, there are two items that
must be configured, jdo metadata, jdo configuration, in which would be part of
this proposal, so I show below an example of the configurations:
/jdoconfig/ sequence unbounded PMF
/jdoconfig/ sequence unbounded Resource
/PMF/
/PMF/@Class
/PMF/@TransactionTimeout
/PMF/@...
/Resource/
/Resource/@Name
/Resource/Connection Settings/
/Resource/Connection Settings/@ConnectionFactoryName
/Resource/Connection Settings/@ConnectionClientID
/Resource/Connection Settings/@ReadOnly
/Resource/Connection Settings/@...
/Resource/Transaction/
/Resource/Transaction/@TwoPhaseCommit
/Resource/Transaction/@Timeout
ConnectionClientID
----------------------------
ConnectionClientID is the identifier for the connection. Some databases such as
Oracle use this to identify the end user (not the connection user).
ConnectionClientID would accept the values:
1 - CredentialMapping - the CredentialMapping takes the principal of the running
application and sets it as client id - eg. ConnectionClientID=CredentialMapping
2 - Identity - the client id is taken from the id right after the Identity word
- eg. ConnectionClientID=Identity:MyUser
ReadOnly
----------------------------
ReadOnly (accepts true, false) will block write operations to this connection
TwoPhaseCommit
--------------------------
Two options:
1 - LastLoggingResource - If the resource is non XA, push down this resource in
commit order.
2 - Emulated - Emulates non XA protocol. Heuristics errors could happen
Example:
<jdoconfig>
<pmf name="snowdog" default-resource="Oracle">
</pmf>
<resource name="ERP">
<connection connectionfactoryname="BSCS_Hot"/>
</resource>
<resource name="PeopleSoft">
<connection connectionfactoryname="PS_Onyx"/>
</resource>
<resource name="Oracle">
<connection connectionfactoryname="ORA_Vinci"
connection-client-id="CredentialMapping"/>
<transaction two-phase-commit="LLR" timeout="30"/>
</resource>
<resource name="Xml">
<connection readonly="true"/>
<extension>
<jpox:xml file="file:/usr/home/myxml.xml <file:///\\usr\home\myxml.xml> "/>
</extension>
</resource>
</jdoconfig>
<jdo>
<package>
<class name="Invoice" resource="ERP"/>
<class name="ClassData"/> <!-- uses default-resource -->
<class name="Person" resource="PeopleSoft"/>
<class name="ReferenceData" resource="Xml"/>
</package>
</jdo>
Quoting Michelle Caisse <Michelle.Caisse@sun.com>:
> Hi,
>
> We will have our regular meeting Friday, October 26 at 9 am PDT to
> discuss JDO TCK issues and status.
>
> Dial-in numbers are:
> 866 230-6968 294-0479#
> International: +1 865 544-7856
>
> Agenda:
>
> 1. Subquery spec update
> 2. Other issues
>
> Action Items from weeks past:
>
> [Oct 12 2007] AI Michael take a look at subquery tck tests.
> https://issues.apache.org/jira/browse/JDO-446
>
> [Sep 14 2007] AI Matthew provide examples for 8.6.1.1 jdoconfig.xml.
>
> [June 22 2007] AI Craig discuss svn:eol-style on email.
>
> [June 22 2007] AI Craig write a proposal on annotation overrides for
> the expert group.
>
> [May 25 2007] AI everyone Download the Grails demo from grails.org and
> check it out. Also look at Grails/Groovy ExpandoMetaClass that has the
> magic to avoid reflection and enhancement.
>
> [May 25 2007] AI Matthew Adams prepare a proposal with just the basics
> of schema synchronization with jdo and orm metadata.
>
> [May 18 2007] AI Craig update http://wiki.apache.org/jdo/
> CurrentDevelopment wiki page
>
> [Apr 27 2007] AI Craig review Query API and send email to experts.
>
> [Apr 27 2007] AI Erik file a JIRA regarding JPA style transactions and
> attach his discussion document to it.
>
> [Mar 9 2007] AI Craig: Update the spec to require that the key of the
> listener is the class name of the listener, for consistency with
> proposed xml..
>
> [Mar 2 2007] AI Craig: update the JDOHelper class to include a string
> constant "META-INF/jdo.xml" and a new method
> getPersistenceManagerFactory taking no arguments.
>
> [Aug 11 2006] AI Craig propose some semantics for behavior if user
> tries to add to a list where the ordering element is incorrect.
>
> [Jul 14 2006] AI: Erik document 220 annotations that don't have a
> corresponding JDO concept.
>
> [Jun 23 2006] AI Martin look at what Hibernate and TopLink support
> for Enum types. In progress.
>
> [Apr 14 2006] AI Craig: update the roadmap for JDO. In progress.
>
> [Nov 4 2005] AI Martin: Update Martin's wiki with discusion of JDK 1.5
> issues. In progress
>
> [Sep 2 2005] AI: To recruit members, update the web site. Articles on
> TheServerSide directing attention to the site. T-shirts, logo. AI:
> Craig write a ServerSide article.
>
> -- Michelle
>
[vbcol=seagreen]
>
| |
| Eric Samson 2007-10-30, 1:11 pm |
| Matthew,
What do you think getConnection()is supposed to return?
A collection of underlying native connections()?
Or is it getConnection(<name> ) (whatever <name> could be)?
Do we need to notion of a default data source or not?
In that case getConnection() with no parameter would return that default data source?
In the case the data source is a Web service, what do you expect as a return value for getConnection()?
Best Regards,
.....: Eric Samson, Founder & CTO, xcalia
Service your Data!
De : Matthew Adams [mailto:matthew@matthewadams.org]
Envoyé : lundi 29 octobre 2007 20:25
Ŕ : Eric Samson
Cc : Erik Bengtson; jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : Re: multiple databases one PM/TX
Hi all,
I like that JDO allows implementations to support this, and I do feel that this could be a differentiator from JPA. The things that come to my mind are the following:
* this should be an optional feature so that we don't slow down implementations from being compliant
* we should examine the proposed JDO 2.1 metadata formats to ensure that it can support but not require multiple data sources
* we need to examine the impact of configuring multiple data sources on the API (i.e., new method JDOHelper.getPersistenceManagerFactory(String... names), PersistenceManager#getDataStoreConnectio
n() & JDOConnection#getNativeConnection?)
* configuration of JTA and the coordination of transactions across all data sources
* this would slow down work on 2.1 -- can we add in another maintenance release?
-matthew
On Oct 29, 2007, at 10:05 AM, Eric Samson wrote:
Hello Erik,
Once again you start an important topic here! :-)
We also are working on a multi-data sources PMF.
I think the name "resource" could be confusing (I tend to prefer "data source").
Maybe the data source properties should be defined elsewhere (as you can have quite complex configurations when you want to access non-relational data stores)?
Best Regards,
.....: Eric Samson, Founder & CTO, Xcalia
Service your Data!
-----Message d'origine-----
De : Erik Bengtson [mailto:erik@jpox.org]
Envoyé : vendredi 26 octobre 2007 15:49
Ŕ : jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : multiple databases one PM/TX
In JPOX we are implementing the access to multiple datastores within a single
PM/TX. If not too late, I'm wonder if you like to hear a proposal to
standardize the configuration of the "jdoconfig" and jdo metadata to be able to
handle this scenario. It may sound overkill, but IMO is a major advance over
JPA.
To introduce the subject, the goal is to handle persistence in multiple
databases (e.g. derby, oracle, DB4O, Versant, XML) within a single JDO
transaction/ single PM. From the user point of view, there are two items that
must be configured, jdo metadata, jdo configuration, in which would be part of
this proposal, so I show below an example of the configurations:
/jdoconfig/ sequence unbounded PMF
/jdoconfig/ sequence unbounded Resource
/PMF/
/PMF/@Class
/PMF/@TransactionTimeout
/PMF/@...
/Resource/
/Resource/@Name
/Resource/Connection Settings/
/Resource/Connection Settings/@ConnectionFactoryName
/Resource/Connection Settings/@ConnectionClientID
/Resource/Connection Settings/@ReadOnly
/Resource/Connection Settings/@...
/Resource/Transaction/
/Resource/Transaction/@TwoPhaseCommit
/Resource/Transaction/@Timeout
ConnectionClientID
----------------------------
ConnectionClientID is the identifier for the connection. Some databases such as
Oracle use this to identify the end user (not the connection user).
ConnectionClientID would accept the values:
1 - CredentialMapping - the CredentialMapping takes the principal of the running
application and sets it as client id - eg. ConnectionClientID=CredentialMapping
2 - Identity - the client id is taken from the id right after the Identity word
- eg. ConnectionClientID=Identity:MyUser
ReadOnly
----------------------------
ReadOnly (accepts true, false) will block write operations to this connection
TwoPhaseCommit
--------------------------
Two options:
1 - LastLoggingResource - If the resource is non XA, push down this resource in
commit order.
2 - Emulated - Emulates non XA protocol. Heuristics errors could happen
Example:
<jdoconfig>
<pmf name="snowdog" default-resource="Oracle">
</pmf>
<resource name="ERP">
<connection connectionfactoryname="BSCS_Hot"/>
</resource>
<resource name="PeopleSoft">
<connection connectionfactoryname="PS_Onyx"/>
</resource>
<resource name="Oracle">
<connection connectionfactoryname="ORA_Vinci"
connection-client-id="CredentialMapping"/>
<transaction two-phase-commit="LLR" timeout="30"/>
</resource>
<resource name="Xml">
<connection readonly="true"/>
<extension>
<jpox:xml file="file:/usr/home/myxml.xml <file:///\\usr\home\myxml.xml> "/>
</extension>
</resource>
</jdoconfig>
<jdo>
<package>
<class name="Invoice" resource="ERP"/>
<class name="ClassData"/> <!-- uses default-resource -->
<class name="Person" resource="PeopleSoft"/>
<class name="ReferenceData" resource="Xml"/>
</package>
</jdo>
Quoting Michelle Caisse <Michelle.Caisse@sun.com>:
> Hi,
>
> We will have our regular meeting Friday, October 26 at 9 am PDT to
> discuss JDO TCK issues and status.
>
> Dial-in numbers are:
> 866 230-6968 294-0479#
> International: +1 865 544-7856
>
> Agenda:
>
> 1. Subquery spec update
> 2. Other issues
>
> Action Items from weeks past:
>
> [Oct 12 2007] AI Michael take a look at subquery tck tests.
> https://issues.apache.org/jira/browse/JDO-446
>
> [Sep 14 2007] AI Matthew provide examples for 8.6.1.1 jdoconfig.xml.
>
> [June 22 2007] AI Craig discuss svn:eol-style on email.
>
> [June 22 2007] AI Craig write a proposal on annotation overrides for
> the expert group.
>
> [May 25 2007] AI everyone Download the Grails demo from grails.org and
> check it out. Also look at Grails/Groovy ExpandoMetaClass that has the
> magic to avoid reflection and enhancement.
>
> [May 25 2007] AI Matthew Adams prepare a proposal with just the basics
> of schema synchronization with jdo and orm metadata.
>
> [May 18 2007] AI Craig update http://wiki.apache.org/jdo/
> CurrentDevelopment wiki page
>
> [Apr 27 2007] AI Craig review Query API and send email to experts.
>
> [Apr 27 2007] AI Erik file a JIRA regarding JPA style transactions and
> attach his discussion document to it.
>
> [Mar 9 2007] AI Craig: Update the spec to require that the key of the
> listener is the class name of the listener, for consistency with
> proposed xml..
>
> [Mar 2 2007] AI Craig: update the JDOHelper class to include a string
> constant "META-INF/jdo.xml" and a new method
> getPersistenceManagerFactory taking no arguments.
>
> [Aug 11 2006] AI Craig propose some semantics for behavior if user
> tries to add to a list where the ordering element is incorrect.
>
> [Jul 14 2006] AI: Erik document 220 annotations that don't have a
> corresponding JDO concept.
>
> [Jun 23 2006] AI Martin look at what Hibernate and TopLink support
> for Enum types. In progress.
>
> [Apr 14 2006] AI Craig: update the roadmap for JDO. In progress.
>
> [Nov 4 2005] AI Martin: Update Martin's wiki with discusion of JDK 1.5
> issues. In progress
>
> [Sep 2 2005] AI: To recruit members, update the web site. Articles on
> TheServerSide directing attention to the site. T-shirts, logo. AI:
> Craig write a ServerSide article.
>
> -- Michelle
>
[vbcol=seagreen]
>
| |
| Joerg von Frantzius 2007-11-05, 7:11 am |
| Hi Erik,
there is one thing that I don't understand about this proposed feature
(which may be just me not seeing the obvious point of course 
Running 2PC on multiple data sources is handled already by J2EE
implementations, and, as far as I recall, there are also libraries
available that provide a JTA without a full blown J2EE server. Why would
you want to duplicate this already existing and available functionality
in JDO?
Regards,
Jörg
Erik Bengtson schrieb:
> In JPOX we are implementing the access to multiple datastores within a single
> PM/TX. If not too late, I’m wonder if you like to hear a proposal to
> standardize the configuration of the “jdoconfig” and jdo metadata to be able to
> handle this scenario. It may sound overkill, but IMO is a major advance over
> JPA.
>
> To introduce the subject, the goal is to handle persistence in multiple
> databases (e.g. derby, oracle, DB4O, Versant, XML) within a single JDO
> transaction/ single PM. From the user point of view, there are two items that
> must be configured, jdo metadata, jdo configuration, in which would be part of
> this proposal, so I show below an example of the configurations:
>
> /jdoconfig/ sequence unbounded PMF
> /jdoconfig/ sequence unbounded Resource
>
> /PMF/
> /PMF/@Class
> /PMF/@TransactionTimeout
> /PMF/@...
> /Resource/
> /Resource/@Name
> /Resource/Connection Settings/
> /Resource/Connection Settings/@ConnectionFactoryName
> /Resource/Connection Settings/@ConnectionClientID
> /Resource/Connection Settings/@ReadOnly
> /Resource/Connection Settings/@...
> /Resource/Transaction/
> /Resource/Transaction/@TwoPhaseCommit
> /Resource/Transaction/@Timeout
>
> ConnectionClientID
> ----------------------------
> ConnectionClientID is the identifier for the connection. Some databases such as
> Oracle use this to identify the end user (not the connection user).
> ConnectionClientID would accept the values:
>
> 1 - CredentialMapping - the CredentialMapping takes the principal of the running
> application and sets it as client id - eg. ConnectionClientID=CredentialMapping
> 2 - Identity – the client id is taken from the id right after the Identity word
> - eg. ConnectionClientID=Identity:MyUser
>
> ReadOnly
> ----------------------------
> ReadOnly (accepts true, false) will block write operations to this connection
>
> TwoPhaseCommit
> --------------------------
> Two options:
>
> 1 – LastLoggingResource - If the resource is non XA, push down this resource in
> commit order.
> 2 – Emulated – Emulates non XA protocol. Heuristics errors could happen
>
> Example:
>
> <jdoconfig>
>
> <pmf name=”snowdog” default-resource=”Oracle”>
> </pmf>
>
> <resource name=”ERP”>
> <connection connectionfactoryname=”BSCS_Hot”/>
> </resource>
>
> <resource name=”PeopleSoft”>
> <connection connectionfactoryname=”PS_Onyx”/>
> </resource>
>
> <resource name=”Oracle”>
> <connection connectionfactoryname=”ORA_Vinci”
> connection-client-id=”CredentialMapping”/>
> <transaction two-phase-commit=”LLR” timeout=”30”/>
> </resource>
>
> <resource name=”Xml”>
> <connection readonly=”true”/>
> <extension>
> <jpox:xml file=”file:/usr/home/myxml.xml”/>
> </extension>
> </resource>
>
>
> </jdoconfig>
>
> <jdo>
> <package>
> <class name=”Invoice” resource=”ERP”/>
> <class name=”ClassData”/> <!-- uses default-resource -->
> <class name=”Person” resource=”PeopleSoft”/>
> <class name=”ReferenceData” resource=”Xml”/>
> </package>
> </jdo>
>
>
>
>
> Quoting Michelle Caisse <Michelle.Caisse@sun.com>:
>
>
>
>
>
>
>
>
| |
| Eric Samson 2007-11-05, 7:11 am |
| SGVsbG8gSm9lcmcsDQoNCkkgZG9uJ3QgdGhpbmsg
RXJpayB3YW50cyB0byByZWludmVudCBKVEEu
DQpQcm9iYWJseSBhIG11bHRpIERCUyBQTUYgaW1w
bGVtZW50YXRpb24gd2lsbCByZWx5IG9uIGEg
SlRBIFRNLg0KQnV0IHlvdSBhbHNvIGhhdmUgdG8g
Y292ZXIgbm9uIHRyYW5zYWN0aW9uYWwgZGF0
YSBzb3VyY2VzLg0KSSB0aGluayB0aGUgcHJvcG9z
ZWQgb3B0aW9ucyBhcmUgaGVyZSB0byBjb3Zl
ciB0aGlzLg0KDQpCZXN0IFJlZ2FyZHMsDQouLi4u
OiBFcmljIFNhbXNvbiwgRm91bmRlciAmIENU
TywgWGNhbGlhDQpTZXJ2aWNlIHlvdXIgRGF0YSEN
Cg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t
LS0tDQpEZcKgOiBKb2VyZyB2b24gRnJhbnR6aXVz
IFttYWlsdG86am9lcmcudm9uLmZyYW50eml1
c0BhcnRub2xvZ3kuY29tXSANCkVudm95w6nCoDog
bHVuZGkgNSBub3ZlbWJyZSAyMDA3IDEwOjI5
DQrDgMKgOiBqZG8tZGV2QGRiLmFwYWNoZS5vcmcN
CkNjwqA6IGpkby1leHBlcnRzLWV4dEBzdW4u
Y29tDQpPYmpldMKgOiBSZTogbXVsdGlwbGUgZGF0
YWJhc2VzIG9uZSBQTS9UWA0KDQpIaSBFcmlr
LA0KDQp0aGVyZSBpcyBvbmUgdGhpbmcgdGhhdCBJ
IGRvbid0IHVuZGVyc3RhbmQgYWJvdXQgdGhp
cyBwcm9wb3NlZCBmZWF0dXJlICh3aGljaCBtYXkg
YmUganVzdCBtZSBub3Qgc2VlaW5nIHRoZSBv
YnZpb3VzIHBvaW50IG9mIGNvdXJzZSA6KQ0KDQpS
dW5uaW5nIDJQQyBvbiBtdWx0aXBsZSBkYXRh
IHNvdXJjZXMgaXMgaGFuZGxlZCBhbHJlYWR5IGJ5
IEoyRUUgaW1wbGVtZW50YXRpb25zLCBhbmQs
IGFzIGZhciBhcyBJIHJlY2FsbCwgdGhlcmUgYXJl
IGFsc28gbGlicmFyaWVzIGF2YWlsYWJsZSB0
aGF0IHByb3ZpZGUgYSBKVEEgd2l0aG91dCBhIGZ1
bGwgYmxvd24gSjJFRSBzZXJ2ZXIuIFdoeSB3
b3VsZCB5b3Ugd2FudCB0byBkdXBsaWNhdGUgdGhp
cyBhbHJlYWR5IGV4aXN0aW5nIGFuZCBhdmFp
bGFibGUgZnVuY3Rpb25hbGl0eSBpbiBKRE8/ DQoNClJlZ2FyZHMsDQpKw7ZyZw0KDQpFcmlrIEJl
bmd0c29uIHNjaHJpZWI6DQo+IEluIEpQT1ggd2Ug
YXJlIGltcGxlbWVudGluZyB0aGUgYWNjZXNz
IHRvIG11bHRpcGxlIGRhdGFzdG9yZXMgd2l0aGlu
IGEgDQo+IHNpbmdsZSBQTS9UWC4gSWYgbm90
IHRvbyBsYXRlLCBJ4oCZbSB3b25kZXIgaWYgeW91
IGxpa2UgdG8gaGVhciBhIA0KPiBwcm9wb3Nh
bCB0byBzdGFuZGFyZGl6ZSB0aGUgY29uZmlndXJh
dGlvbiBvZiB0aGUg4oCcamRvY29uZmln4oCd
IGFuZCBqZG8gDQo+IG1ldGFkYXRhIHRvIGJlIGFi
bGUgdG8gaGFuZGxlIHRoaXMgc2NlbmFyaW8u
IEl0IG1heSBzb3VuZCBvdmVya2lsbCwgDQo+IGJ1
dCBJTU8gaXMgYSBtYWpvciBhZHZhbmNlIG92
ZXIgSlBBLg0KPg0KPiBUbyBpbnRyb2R1Y2UgdGhl
IHN1YmplY3QsIHRoZSBnb2FsIGlzIHRvIGhh
bmRsZSBwZXJzaXN0ZW5jZSBpbiANCj4gbXVsdGlw
bGUgZGF0YWJhc2VzIChlLmcuIGRlcmJ5LCBv
cmFjbGUsIERCNE8sIFZlcnNhbnQsIFhNTCkgd2l0
aGluIGEgDQo+IHNpbmdsZSBKRE8gdHJhbnNh
Y3Rpb24vIHNpbmdsZSBQTS4gRnJvbSB0aGUgdXNl
ciBwb2ludCBvZiB2aWV3LCB0aGVyZSANCj4g
YXJlIHR3byBpdGVtcyB0aGF0IG11c3QgYmUgY29u
ZmlndXJlZCwgamRvIG1ldGFkYXRhLCBqZG8g
DQo+IGNvbmZpZ3VyYXRpb24sIGluIHdoaWNoIHdv
dWxkIGJlIHBhcnQgb2YgdGhpcyBwcm9wb3Nh
bCwgc28gSSBzaG93IGJlbG93IGFuIGV4YW1wbGUg
b2YgdGhlIGNvbmZpZ3VyYXRpb25zOg0KPg0K
PiAvamRvY29uZmlnLyBzZXF1ZW5jZSB1bmJvdW5k
ZWQgUE1GDQo+IC9qZG9jb25maWcvIHNlcXVl
bmNlIHVuYm91bmRlZCBSZXNvdXJjZQ0KPg0KPiAv
UE1GLw0KPiAvUE1GL0BDbGFzcw0KPiAvUE1G
L0BUcmFuc2FjdGlvblRpbWVvdXQNCj4gL1BNRi9A
Li4uDQo+IC9SZXNvdXJjZS8NCj4gL1Jlc291
cmNlL0BOYW1lDQo+IC9SZXNvdXJjZS9Db25uZWN0
aW9uIFNldHRpbmdzLw0KPiAvUmVzb3VyY2Uv
Q29ubmVjdGlvbiBTZXR0aW5ncy9AQ29ubmVjdGlv
bkZhY3RvcnlOYW1lIA0KPiAvUmVzb3VyY2Uv
Q29ubmVjdGlvbiBTZXR0aW5ncy9AQ29ubmVjdGlv
bkNsaWVudElEIC9SZXNvdXJjZS9Db25uZWN0
aW9uIA0KPiBTZXR0aW5ncy9AUmVhZE9ubHkgL1Jl
c291cmNlL0Nvbm5lY3Rpb24gU2V0dGluZ3Mv
QC4uLg0KPiAvUmVzb3VyY2UvVHJhbnNhY3Rpb24v
DQo+IC9SZXNvdXJjZS9UcmFuc2FjdGlvbi9A
VHdvUGhhc2VDb21taXQNCj4gL1Jlc291cmNlL1Ry
YW5zYWN0aW9uL0BUaW1lb3V0DQo+DQo+IENv
bm5lY3Rpb25DbGllbnRJRA0KPiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+IENvbm5l
Y3Rpb25DbGllbnRJRCBpcyB0aGUgaWRlbnRpZmll
ciBmb3IgdGhlIGNvbm5lY3Rpb24uIFNvbWUg
DQo+IGRhdGFiYXNlcyBzdWNoIGFzIE9yYWNsZSB1
c2UgdGhpcyB0byBpZGVudGlmeSB0aGUgZW5k
IHVzZXIgKG5vdCB0aGUgY29ubmVjdGlvbiB1c2Vy
KS4NCj4gQ29ubmVjdGlvbkNsaWVudElEIHdv
dWxkIGFjY2VwdCB0aGUgdmFsdWVzOg0KPg0KPiAx
IC0gQ3JlZGVudGlhbE1hcHBpbmcgLSB0aGUg
Q3JlZGVudGlhbE1hcHBpbmcgdGFrZXMgdGhlIHBy
aW5jaXBhbCBvZiANCj4gdGhlIHJ1bm5pbmcg
YXBwbGljYXRpb24gYW5kIHNldHMgaXQgYXMgY2xp
ZW50IGlkIC0gZWcuIA0KPiBDb25uZWN0aW9u
Q2xpZW50SUQ9Q3JlZGVudGlhbE1hcHBpbmcNCj4g
MiAtIElkZW50aXR5IOKAkyB0aGUgY2xpZW50
IGlkIGlzIHRha2VuIGZyb20gdGhlIGlkIHJpZ2h0
IGFmdGVyIHRoZSANCj4gSWRlbnRpdHkgd29y
ZA0KPiAtIGVnLiBDb25uZWN0aW9uQ2xpZW50SUQ9
SWRlbnRpdHk6TXlVc2VyDQo+DQo+IFJlYWRP
bmx5DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCj4gUmVhZE9ubHkgKGFjY2VwdHMg
dHJ1ZSwgZmFsc2UpIHdpbGwgYmxvY2sgd3JpdGUg
b3BlcmF0aW9ucyB0byB0aGlzIA0KPiBjb25u
ZWN0aW9uDQo+DQo+IFR3b1BoYXNlQ29tbWl0DQo+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQo+IFR3byBvcHRpb25zOg0KPg0KPiAxIOKAkyBM
YXN0TG9nZ2luZ1Jlc291cmNlIC0gSWYgdGhl
IHJlc291cmNlIGlzIG5vbiBYQSwgcHVzaCBkb3du
IHRoaXMgDQo+IHJlc291cmNlIGluIGNvbW1p
dCBvcmRlci4NCj4gMiDigJMgRW11bGF0ZWQg4oCT
IEVtdWxhdGVzIG5vbiBYQSBwcm90b2NvbC4g
SGV1cmlzdGljcyBlcnJvcnMgY291bGQgDQo+IGhh
cHBlbg0KPg0KPiBFeGFtcGxlOg0KPg0KPiA8
amRvY29uZmlnPg0KPg0KPiA8cG1mIG5hbWU94oCd
c25vd2RvZ+KAnSBkZWZhdWx0LXJlc291cmNl
PeKAnU9yYWNsZeKAnT4gPC9wbWY+DQo+DQo+IDxy
ZXNvdXJjZSBuYW1lPeKAnUVSUOKAnT4NCj4g
PGNvbm5lY3Rpb24gY29ubmVjdGlvbmZhY3Rvcnlu
YW1lPeKAnUJTQ1NfSG904oCdLz4NCj4gPC9y
ZXNvdXJjZT4NCj4NCj4gPHJlc291cmNlIG5hbWU9
4oCdUGVvcGxlU29mdOKAnT4NCj4gPGNvbm5l
Y3Rpb24gY29ubmVjdGlvbmZhY3RvcnluYW1lPeKA
nVBTX09ueXjigJ0vPiA8L3Jlc291cmNlPg0K
Pg0KPiA8cmVzb3VyY2UgbmFtZT3igJ1PcmFjbGXi
gJ0+DQo+IDxjb25uZWN0aW9uIGNvbm5lY3Rp
b25mYWN0b3J5bmFtZT3igJ1PUkFfVmluY2nigJ0N
Cj4gY29ubmVjdGlvbi1jbGllbnQtaWQ94oCd
Q3JlZGVudGlhbE1hcHBpbmfigJ0vPg0KPiA8dHJh
bnNhY3Rpb24gdHdvLXBoYXNlLWNvbW1pdD3i
gJ1MTFLigJ0gdGltZW91dD3igJ0zMOKAnS8+IDwv
cmVzb3VyY2U+DQo+DQo+IDxyZXNvdXJjZSBu
YW1lPeKAnVhtbOKAnT4NCj4gPGNvbm5lY3Rpb24g
cmVhZG9ubHk94oCddHJ1ZeKAnS8+DQo+IDxl
eHRlbnNpb24+DQo+IDxqcG94OnhtbCBmaWxlPeKA
nWZpbGU6L3Vzci9ob21lL215eG1sLnhtbOKA
nS8+IDwvZXh0ZW5zaW9uPiA8L3Jlc291cmNlPg0K
Pg0KPg0KPiA8L2pkb2NvbmZpZz4NCj4NCj4g
PGpkbz4NCj4gPHBhY2thZ2U+DQo+IDxjbGFzcyBu
YW1lPeKAnUludm9pY2XigJ0gcmVzb3VyY2U9
4oCdRVJQ4oCdLz4gPGNsYXNzIG5hbWU94oCdQ2xh
c3NEYXRh4oCdLz4gPCEtLSANCj4gdXNlcyBk
ZWZhdWx0LXJlc291cmNlIC0tPiA8Y2xhc3MgbmFt
ZT3igJ1QZXJzb27igJ0gcmVzb3VyY2U94oCd
UGVvcGxlU29mdOKAnS8+IA0KPiA8Y2xhc3MgbmFt
ZT3igJ1SZWZlcmVuY2VEYXRh4oCdIHJlc291
cmNlPeKAnVhtbOKAnS8+IDwvcGFja2FnZT4gPC9q
ZG8+DQo+DQo+DQo+DQo+DQo+IFF1b3Rpbmcg
TWljaGVsbGUgQ2Fpc3NlIDxNaWNoZWxsZS5DYWlz
c2VAc3VuLmNvbT46DQo+DQo+ICAgDQo+PiBI
aSwNCj4+DQo+PiBXZSB3aWxsIGhhdmUgb3VyIHJl
Z3VsYXIgbWVldGluZyBGcmlkYXksIE9jdG9i
ZXIgMjYgYXQgOSBhbSBQRFQgdG8gDQo+PiBkaXNj
dXNzIEpETyBUQ0sgaXNzdWVzIGFuZCBzdGF0
dXMuDQo+Pg0KPj4gRGlhbC1pbiBudW1iZXJzIGFy
ZToNCj4+IDg2NiAyMzAtNjk2OCAgIDI5NC0w
NDc5Iw0KPj4gSW50ZXJuYXRpb25hbDogKzEgODY1
IDU0NC03ODU2DQo+Pg0KPj4gQWdlbmRhOg0K
Pj4NCj4+IDEuIFN1YnF1ZXJ5IHNwZWMgdXBkYXRl
DQo+PiAyLiBPdGhlciBpc3N1ZXMNCj4+DQo+
PiBBY3Rpb24gSXRlbXMgZnJvbSB3ZWVrcyBwYXN0
Og0KPj4NCj4+IFtPY3QgMTIgMjAwN10gQUkg
TWljaGFlbCB0YWtlIGEgbG9vayBhdCBzdWJxdWVy
eSB0Y2sgdGVzdHMuDQo+PiBodHRwczovL2lz
c3Vlcy5hcGFjaGUub3JnL2ppcmEvYnJvd3NlL0pE
Ty00NDYNCj4+DQo+PiBbU2VwIDE0IDIwMDdd
IEFJIE1hdHRoZXcgcHJvdmlkZSBleGFtcGxlcyBm
b3IgOC42LjEuMSBqZG9jb25maWcueG1sLg0K
Pj4NCj4+IFtKdW5lIDIyIDIwMDddIEFJIENyYWln
IGRpc2N1c3Mgc3ZuOmVvbC1zdHlsZSBvbiBl
bWFpbC4NCj4+DQo+PiBbSnVuZSAyMiAyMDA3XSBB
SSBDcmFpZyB3cml0ZSBhIHByb3Bvc2FsIG9u
IGFubm90YXRpb24gb3ZlcnJpZGVzIGZvciANCj4+
IHRoZSBleHBlcnQgZ3JvdXAuDQo+Pg0KPj4g
W01heSAyNSAyMDA3XSAgQUkgZXZlcnlvbmUgRG93
bmxvYWQgdGhlIEdyYWlscyBkZW1vIGZyb20g
Z3JhaWxzLm9yZyAgDQo+PiBhbmQgY2hlY2sgaXQg
b3V0LiBBbHNvIGxvb2sgYXQgR3JhaWxzL0dy
b292eSBFeHBhbmRvTWV0YUNsYXNzIHRoYXQgIA0K
Pj4gaGFzIHRoZSBtYWdpYyB0byBhdm9pZCBy
ZWZsZWN0aW9uIGFuZCBlbmhhbmNlbWVudC4NCj4+
DQo+PiBbTWF5IDI1IDIwMDddIEFJIE1hdHRo
ZXcgQWRhbXMgcHJlcGFyZSBhIHByb3Bvc2FsIHdp
dGgganVzdCB0aGUgIA0KPj4gYmFzaWNzIG9m
IHNjaGVtYSBzeW5jaHJvbml6YXRpb24gd2l0aCBq
ZG8gYW5kIG9ybSBtZXRhZGF0YS4NCj4+DQo+
PiBbTWF5IDE4IDIwMDddIEFJIENyYWlnIHVwZGF0
ZSBodHRwOi8vd2lraS5hcGFjaGUub3JnL2pk
by8gDQo+PiBDdXJyZW50RGV2ZWxvcG1lbnQgd2lr
aSBwYWdlDQo+Pg0KPj4gW0FwciAyNyAyMDA3
XSBBSSBDcmFpZyByZXZpZXcgUXVlcnkgQVBJIGFu
ZCBzZW5kIGVtYWlsIHRvIGV4cGVydHMuDQo+
Pg0KPj4gW0FwciAyNyAyMDA3XSBBSSBFcmlrIGZp
bGUgYSBKSVJBIHJlZ2FyZGluZyBKUEEgc3R5
bGUgdHJhbnNhY3Rpb25zICANCj4+IGFuZCBhdHRh
Y2ggaGlzIGRpc2N1c3Npb24gZG9jdW1lbnQg
dG8gaXQuDQo+Pg0KPj4gW01hciA5IDIwMDddIEFJ
IENyYWlnOiBVcGRhdGUgdGhlIHNwZWMgdG8g
cmVxdWlyZSB0aGF0IHRoZSBrZXkgb2YgdGhlIA0K
Pj4gbGlzdGVuZXIgaXMgdGhlIGNsYXNzIG5h
bWUgb2YgdGhlIGxpc3RlbmVyLCBmb3IgY29uc2lz
dGVuY3kgd2l0aCANCj4+IHByb3Bvc2VkIHht
bC4uDQo+Pg0KPj4gW01hciAyIDIwMDddIEFJIENy
YWlnOiB1cGRhdGUgdGhlIEpET0hlbHBlciBj
bGFzcyB0byBpbmNsdWRlIGEgc3RyaW5nIA0KPj4g
Y29uc3RhbnQgIk1FVEEtSU5GL2pkby54bWwi
IGFuZCBhIG5ldyBtZXRob2QgDQo+PiBnZXRQZXJz
aXN0ZW5jZU1hbmFnZXJGYWN0b3J5IHRha2lu
ZyBubyBhcmd1bWVudHMuDQo+Pg0KPj4gW0F1ZyAx
MSAyMDA2XSBBSSBDcmFpZyBwcm9wb3NlIHNv
bWUgc2VtYW50aWNzIGZvciBiZWhhdmlvciBpZiB1
c2VyIA0KPj4gdHJpZXMgdG8gYWRkIHRvIGEg
bGlzdCB3aGVyZSB0aGUgb3JkZXJpbmcgZWxlbWVu
dCBpcyBpbmNvcnJlY3QuDQo+Pg0KPj4gW0p1
bCAxNCAyMDA2XSBBSTogRXJpayBkb2N1bWVudCAy
MjAgYW5ub3RhdGlvbnMgdGhhdCBkb24ndCBo
YXZlIGEgDQo+PiBjb3JyZXNwb25kaW5nIEpETyBj
b25jZXB0Lg0KPj4NCj4+IFtKdW4gMjMgMjAw
Nl0gIEFJICBNYXJ0aW4gbG9vayBhdCB3aGF0IEhp
YmVybmF0ZSBhbmQgVG9wTGluayBzdXBwb3J0
IA0KPj4gZm9yIEVudW0gdHlwZXMuIEluIHByb2dy
ZXNzLg0KPj4NCj4+IFtBcHIgMTQgMjAwNl0g
QUkgQ3JhaWc6IHVwZGF0ZSB0aGUgcm9hZG1hcCBm
b3IgSkRPLiBJbiBwcm9ncmVzcy4NCj4+DQo+
PiBbTm92IDQgMjAwNV0gQUkgTWFydGluOiBVcGRh
dGUgTWFydGluJ3Mgd2lraSB3aXRoIGRpc2N1
c2lvbiBvZiBKREsgICAxLjUNCj4+IGlzc3Vlcy4g
SW4gcHJvZ3Jlc3MNCj4+DQo+PiBbU2VwIDIg
MjAwNV0gQUk6IFRvIHJlY3J1aXQgbWVtYmVycywg
dXBkYXRlIHRoZSB3ZWIgc2l0ZS4gQXJ0aWNs
ZXMgIG9uDQo+PiBUaGVTZXJ2ZXJTaWRlIGRpcmVj
dGluZyBhdHRlbnRpb24gdG8gdGhlIHNpdGUu
IFQtc2hpcnRzLCBsb2dvLiAgICBBSToNCj4+IENy
YWlnIHdyaXRlIGEgU2VydmVyU2lkZSBhcnRp
Y2xlLg0KPj4NCj4+IC0tIE1pY2hlbGxlDQo+Pg0K
Pj4gICAgIA0KPg0KPg0KPg0KPg0KPg0KPiAg
IA0KDQo=
| |
| Joerg von Frantzius 2007-11-05, 7:11 am |
| Hi Erik,
OK now I got it, you want to support fields within the same PC class to
be persisted to different datasources, right?
Erik Bengtson schrieb:
> Jorg,
>
> An example:
>
> Class product
>
> Field name ; //oracle
> Field price ; //erp
> Field instock ; //erp
>
> With multiple databases feature, you can load an object distributed in multiples databases. As Eric said we will not reinvent JTA.
>
> Each implementation can use JTA to support transactions with multiple datasources, but can use any other mechanism (not defined). JPOX is pluggable and enabled to accept any jta implementation.
>
> If you don't provide an external jta implementation, JPOX will use its internal implementation.
> -- BlackBerry® from Mobistar ---
>
> -----Original Message-----
> From: Joerg von Frantzius <joerg.von.frantzius@artnology.com>
>
> Date: Mon, 05 Nov 2007 10:28:55
> To:jdo-dev@db.apache.org
> Cc:jdo-experts-ext@sun.com
> Subject: Re: multiple databases one PM/TX
>
>
> Hi Erik,
>
> there is one thing that I don't understand about this proposed feature
> (which may be just me not seeing the obvious point of course
>
> Running 2PC on multiple data sources is handled already by J2EE
> implementations, and, as far as I recall, there are also libraries
> available that provide a JTA without a full blown J2EE server. Why would
> you want to duplicate this already existing and available functionality
> in JDO?
>
> Regards,
> Jörg
>
> Erik Bengtson schrieb:
>
>
>
>
| |
| Erik Bengtson 2007-11-05, 7:11 am |
| Sm9yZywNCg0KQW4gZXhhbXBsZToNCg0KQ2xhc3Mg
cHJvZHVjdA0KDQpGaWVsZCBuYW1lIDsgLy9v
cmFjbGUNCkZpZWxkIHByaWNlIDsgLy9lcnANCkZp
ZWxkIGluc3RvY2sgOyAvL2VycA0KDQpXaXRo
IG11bHRpcGxlIGRhdGFiYXNlcyBmZWF0dXJlLCB5
b3UgY2FuIGxvYWQgYW4gb2JqZWN0IGRpc3Ry
aWJ1dGVkIGluIG11bHRpcGxlcyBkYXRhYmFzZXMu
IEFzIEVyaWMgc2FpZCB3ZSB3aWxsIG5vdCBy
ZWludmVudCBKVEEuDQoNCkVhY2ggaW1wbGVtZW50
YXRpb24gY2FuIHVzZSBKVEEgdG8gc3VwcG9y
dCB0cmFuc2FjdGlvbnMgd2l0aCBtdWx0aXBsZSBk
YXRhc291cmNlcywgYnV0IGNhbiB1c2UgYW55
IG90aGVyIG1lY2hhbmlzbSAobm90IGRlZmluZWQp
LiBKUE9YIGlzIHBsdWdnYWJsZSBhbmQgZW5h
YmxlZCB0byBhY2NlcHQgYW55IGp0YSBpbXBsZW1l
bnRhdGlvbi4gIA0KDQpJZiB5b3UgZG9uJ3Qg
cHJvdmlkZSBhbiBleHRlcm5hbCBqdGEgaW1wbGVt
ZW50YXRpb24sIEpQT1ggd2lsbCB1c2UgaXRz
IGludGVybmFsIGltcGxlbWVudGF0aW9uLg0KLS0g
ICBCbGFja0JlcnJ5wq4gZnJvbSBNb2Jpc3Rh
ciAgICAtLS0NCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IEpvZXJnIHZvbiBG
cmFudHppdXMgPGpvZXJnLnZvbi5mcmFudHppdXNA
YXJ0bm9sb2d5LmNvbT4NCg0KRGF0ZTogTW9u
LCAwNSBOb3YgMjAwNyAxMDoyODo1NSANClRvOmpk
by1kZXZAZGIuYXBhY2hlLm9yZw0KQ2M6amRv
LWV4cGVydHMtZXh0QHN1bi5jb20NClN1YmplY3Q6
IFJlOiBtdWx0aXBsZSBkYXRhYmFzZXMgb25l
IFBNL1RYDQoNCg0KSGkgRXJpaywNCg0KdGhlcmUg
aXMgb25lIHRoaW5nIHRoYXQgSSBkb24ndCB1
bmRlcnN0YW5kIGFib3V0IHRoaXMgcHJvcG9zZWQg
ZmVhdHVyZQ0KKHdoaWNoIG1heSBiZSBqdXN0
IG1lIG5vdCBzZWVpbmcgdGhlIG9idmlvdXMgcG9p
bnQgb2YgY291cnNlIDopDQoNClJ1bm5pbmcg
MlBDIG9uIG11bHRpcGxlIGRhdGEgc291cmNlcyBp
cyBoYW5kbGVkIGFscmVhZHkgYnkgSjJFRQ0K
aW1wbGVtZW50YXRpb25zLCBhbmQsIGFzIGZhciBh
cyBJIHJlY2FsbCwgdGhlcmUgYXJlIGFsc28g
bGlicmFyaWVzDQphdmFpbGFibGUgdGhhdCBwcm92
aWRlIGEgSlRBIHdpdGhvdXQgYSBmdWxsIGJs
b3duIEoyRUUgc2VydmVyLiBXaHkgd291bGQNCnlv
dSB3YW50IHRvIGR1cGxpY2F0ZSB0aGlzIGFs
cmVhZHkgZXhpc3RpbmcgYW5kIGF2YWlsYWJsZSBm
dW5jdGlvbmFsaXR5DQppbiBKRE8/DQoNClJl
Z2FyZHMsDQpKw7ZyZw0KDQpFcmlrIEJlbmd0c29u
IHNjaHJpZWI6DQo+IEluIEpQT1ggd2UgYXJl
IGltcGxlbWVudGluZyB0aGUgYWNjZXNzIHRvIG11
bHRpcGxlIGRhdGFzdG9yZXMgd2l0aGluIGEg
c2luZ2xlDQo+IFBNL1RYLiBJZiBub3QgdG9vIGxh
dGUsIEnigJltIHdvbmRlciBpZiB5b3UgbGlr
ZSB0byBoZWFyIGEgcHJvcG9zYWwgdG8NCj4gc3Rh
bmRhcmRpemUgdGhlIGNvbmZpZ3VyYXRpb24g
b2YgdGhlIOKAnGpkb2NvbmZpZ+KAnSBhbmQgamRv
IG1ldGFkYXRhIHRvIGJlIGFibGUgdG8NCj4g
aGFuZGxlIHRoaXMgc2NlbmFyaW8uIEl0IG1heSBz
b3VuZCBvdmVya2lsbCwgYnV0IElNTyBpcyBh
IG1ham9yIGFkdmFuY2Ugb3Zlcg0KPiBKUEEuDQo+
DQo+IFRvIGludHJvZHVjZSB0aGUgc3ViamVj
dCwgdGhlIGdvYWwgaXMgdG8gaGFuZGxlIHBlcnNp
c3RlbmNlIGluIG11bHRpcGxlDQo+IGRhdGFi
YXNlcyAoZS5nLiBkZXJieSwgb3JhY2xlLCBEQjRP
LCBWZXJzYW50LCBYTUwpIHdpdGhpbiBhIHNp
bmdsZSBKRE8NCj4gdHJhbnNhY3Rpb24vIHNpbmds
ZSBQTS4gRnJvbSB0aGUgdXNlciBwb2ludCBv
ZiB2aWV3LCB0aGVyZSBhcmUgdHdvIGl0ZW1zIHRo
YXQNCj4gbXVzdCBiZSBjb25maWd1cmVkLCBq
ZG8gbWV0YWRhdGEsIGpkbyBjb25maWd1cmF0aW9u
LCBpbiB3aGljaCB3b3VsZCBiZSBwYXJ0IG9m
DQo+IHRoaXMgcHJvcG9zYWwsIHNvIEkgc2hvdyBi
ZWxvdyBhbiBleGFtcGxlIG9mIHRoZSBjb25m
aWd1cmF0aW9uczoNCj4NCj4gL2pkb2NvbmZpZy8g
c2VxdWVuY2UgdW5ib3VuZGVkIFBNRg0KPiAv
amRvY29uZmlnLyBzZXF1ZW5jZSB1bmJvdW5kZWQg
UmVzb3VyY2UNCj4NCj4gL1BNRi8NCj4gL1BN
Ri9AQ2xhc3MNCj4gL1BNRi9AVHJhbnNhY3Rpb25U
aW1lb3V0DQo+IC9QTUYvQC4uLg0KPiAvUmVz
b3VyY2UvDQo+IC9SZXNvdXJjZS9ATmFtZQ0KPiAv
UmVzb3VyY2UvQ29ubmVjdGlvbiBTZXR0aW5n
cy8NCj4gL1Jlc291cmNlL0Nvbm5lY3Rpb24gU2V0
dGluZ3MvQENvbm5lY3Rpb25GYWN0b3J5TmFt
ZQ0KPiAvUmVzb3VyY2UvQ29ubmVjdGlvbiBTZXR0
aW5ncy9AQ29ubmVjdGlvbkNsaWVudElEDQo+
IC9SZXNvdXJjZS9Db25uZWN0aW9uIFNldHRpbmdz
L0BSZWFkT25seQ0KPiAvUmVzb3VyY2UvQ29u
bmVjdGlvbiBTZXR0aW5ncy9ALi4uDQo+IC9SZXNv
dXJjZS9UcmFuc2FjdGlvbi8NCj4gL1Jlc291
cmNlL1RyYW5zYWN0aW9uL0BUd29QaGFzZUNvbW1p
dA0KPiAvUmVzb3VyY2UvVHJhbnNhY3Rpb24v
QFRpbWVvdXQNCj4NCj4gQ29ubmVjdGlvbkNsaWVu
dElEDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCj4gQ29ubmVjdGlvbkNsaWVudElE
IGlzIHRoZSBpZGVudGlmaWVyIGZvciB0aGUg
Y29ubmVjdGlvbi4gU29tZSBkYXRhYmFzZXMgc3Vj
aCBhcw0KPiBPcmFjbGUgdXNlIHRoaXMgdG8g
aWRlbnRpZnkgdGhlIGVuZCB1c2VyIChub3QgdGhl
IGNvbm5lY3Rpb24gdXNlcikuDQo+IENvbm5l
Y3Rpb25DbGllbnRJRCB3b3VsZCBhY2NlcHQgdGhl
IHZhbHVlczoNCj4NCj4gMSAtIENyZWRlbnRp
YWxNYXBwaW5nIC0gdGhlIENyZWRlbnRpYWxNYXBw
aW5nIHRha2VzIHRoZSBwcmluY2lwYWwgb2Yg
dGhlIHJ1bm5pbmcNCj4gYXBwbGljYXRpb24gYW5k
IHNldHMgaXQgYXMgY2xpZW50IGlkIC0gZWcu
IENvbm5lY3Rpb25DbGllbnRJRD1DcmVkZW50aWFs
TWFwcGluZw0KPiAyIC0gSWRlbnRpdHkg4oCT
IHRoZSBjbGllbnQgaWQgaXMgdGFrZW4gZnJvbSB0
aGUgaWQgcmlnaHQgYWZ0ZXIgdGhlIElkZW50
aXR5IHdvcmQNCj4gLSBlZy4gQ29ubmVjdGlvbkNs
aWVudElEPUlkZW50aXR5Ok15VXNlcg0KPg0K
PiBSZWFkT25seQ0KPiAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+IFJlYWRPbmx5IChh
Y2NlcHRzIHRydWUsIGZhbHNlKSB3aWxsIGJsb2Nr
IHdyaXRlIG9wZXJhdGlvbnMgdG8gdGhpcyBj
b25uZWN0aW9uDQo+DQo+IFR3b1BoYXNlQ29tbWl0
DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQo+IFR3byBvcHRpb25zOg0KPg0KPiAxIOKA
kyBMYXN0TG9nZ2luZ1Jlc291cmNlIC0gSWYg
dGhlIHJlc291cmNlIGlzIG5vbiBYQSwgcHVzaCBk
b3duIHRoaXMgcmVzb3VyY2UgaW4NCj4gY29t
bWl0IG9yZGVyLg0KPiAyIOKAkyBFbXVsYXRlZCDi
gJMgRW11bGF0ZXMgbm9uIFhBIHByb3RvY29s
LiBIZXVyaXN0aWNzIGVycm9ycyBjb3VsZCBoYXBw
ZW4NCj4NCj4gRXhhbXBsZToNCj4NCj4gPGpk
b2NvbmZpZz4NCj4NCj4gPHBtZiBuYW1lPeKAnXNu
b3dkb2figJ0gZGVmYXVsdC1yZXNvdXJjZT3i
gJ1PcmFjbGXigJ0+DQo+IDwvcG1mPg0KPg0KPiA8
cmVzb3VyY2UgbmFtZT3igJ1FUlDigJ0+DQo+
IDxjb25uZWN0aW9uIGNvbm5lY3Rpb25mYWN0b3J5
bmFtZT3igJ1CU0NTX0hvdOKAnS8+DQo+IDwv
cmVzb3VyY2U+DQo+DQo+IDxyZXNvdXJjZSBuYW1l
PeKAnVBlb3BsZVNvZnTigJ0+DQo+IDxjb25u
ZWN0aW9uIGNvbm5lY3Rpb25mYWN0b3J5bmFtZT3i
gJ1QU19Pbnl44oCdLz4NCj4gPC9yZXNvdXJj
ZT4NCj4NCj4gPHJlc291cmNlIG5hbWU94oCdT3Jh
Y2xl4oCdPg0KPiA8Y29ubmVjdGlvbiBjb25u
ZWN0aW9uZmFjdG9yeW5hbWU94oCdT1JBX1ZpbmNp
4oCdDQo+IGNvbm5lY3Rpb24tY2xpZW50LWlk
PeKAnUNyZWRlbnRpYWxNYXBwaW5n4oCdLz4NCj4g
PHRyYW5zYWN0aW9uIHR3by1waGFzZS1jb21t
aXQ94oCdTExS4oCdIHRpbWVvdXQ94oCdMzDigJ0v
Pg0KPiA8L3Jlc291cmNlPg0KPg0KPiA8cmVz
b3VyY2UgbmFtZT3igJ1YbWzigJ0+DQo+IDxjb25u
ZWN0aW9uIHJlYWRvbmx5PeKAnXRydWXigJ0v
Pg0KPiA8ZXh0ZW5zaW9uPg0KPiA8anBveDp4bWwg
ZmlsZT3igJ1maWxlOi91c3IvaG9tZS9teXht
bC54bWzigJ0vPg0KPiA8L2V4dGVuc2lvbj4NCj4g
PC9yZXNvdXJjZT4NCj4NCj4NCj4gPC9qZG9j
b25maWc+DQo+DQo+IDxqZG8+DQo+IDxwYWNrYWdl
Pg0KPiA8Y2xhc3MgbmFtZT3igJ1JbnZvaWNl
4oCdIHJlc291cmNlPeKAnUVSUOKAnS8+DQo+IDxj
bGFzcyBuYW1lPeKAnUNsYXNzRGF0YeKAnS8+
IDwhLS0gdXNlcyBkZWZhdWx0LXJlc291cmNlIC0t
Pg0KPiA8Y2xhc3MgbmFtZT3igJ1QZXJzb27i
gJ0gcmVzb3VyY2U94oCdUGVvcGxlU29mdOKAnS8+
DQo+IDxjbGFzcyBuYW1lPeKAnVJlZmVyZW5j
ZURhdGHigJ0gcmVzb3VyY2U94oCdWG1s4oCdLz4N
Cj4gPC9wYWNrYWdlPg0KPiA8L2pkbz4NCj4N
Cj4NCj4NCj4NCj4gUXVvdGluZyBNaWNoZWxsZSBD
YWlzc2UgPE1pY2hlbGxlLkNhaXNzZUBzdW4u
Y29tPjoNCj4NCj4gICANCj4+IEhpLA0KPj4NCj4+
IFdlIHdpbGwgaGF2ZSBvdXIgcmVndWxhciBt
ZWV0aW5nIEZyaWRheSwgT2N0b2JlciAyNiBhdCA5
IGFtIFBEVCB0bw0KPj4gZGlzY3VzcyBKRE8g
VENLIGlzc3VlcyBhbmQgc3RhdHVzLg0KPj4NCj4+
IERpYWwtaW4gbnVtYmVycyBhcmU6DQo+PiA4
NjYgMjMwLTY5NjggICAyOTQtMDQ3OSMNCj4+IElu
dGVybmF0aW9uYWw6ICsxIDg2NSA1NDQtNzg1
Ng0KPj4NCj4+IEFnZW5kYToNCj4+DQo+PiAxLiBT
dWJxdWVyeSBzcGVjIHVwZGF0ZQ0KPj4gMi4g
T3RoZXIgaXNzdWVzDQo+Pg0KPj4gQWN0aW9uIEl0
ZW1zIGZyb20gd2Vla3MgcGFzdDoNCj4+DQo+
PiBbT2N0IDEyIDIwMDddIEFJIE1pY2hhZWwgdGFr
ZSBhIGxvb2sgYXQgc3VicXVlcnkgdGNrIHRl
c3RzLg0KPj4gaHR0cHM6Ly9pc3N1ZXMuYXBhY2hl
Lm9yZy9qaXJhL2Jyb3dzZS9KRE8tNDQ2DQo+
Pg0KPj4gW1NlcCAxNCAyMDA3XSBBSSBNYXR0aGV3
IHByb3ZpZGUgZXhhbXBsZXMgZm9yIDguNi4x
LjEgamRvY29uZmlnLnhtbC4NCj4+DQo+PiBbSnVu
ZSAyMiAyMDA3XSBBSSBDcmFpZyBkaXNjdXNz
IHN2bjplb2wtc3R5bGUgb24gZW1haWwuDQo+Pg0K
Pj4gW0p1bmUgMjIgMjAwN10gQUkgQ3JhaWcg
d3JpdGUgYSBwcm9wb3NhbCBvbiBhbm5vdGF0aW9u
IG92ZXJyaWRlcyBmb3INCj4+IHRoZSBleHBl
cnQgZ3JvdXAuDQo+Pg0KPj4gW01heSAyNSAyMDA3
XSAgQUkgZXZlcnlvbmUgRG93bmxvYWQgdGhl
IEdyYWlscyBkZW1vIGZyb20gZ3JhaWxzLm9yZyAg
YW5kDQo+PiBjaGVjayBpdCBvdXQuIEFsc28g
bG9vayBhdCBHcmFpbHMvR3Jvb3Z5IEV4cGFuZG9N
ZXRhQ2xhc3MgdGhhdCAgaGFzIHRoZQ0KPj4g
bWFnaWMgdG8gYXZvaWQgcmVmbGVjdGlvbiBhbmQg
ZW5oYW5jZW1lbnQuDQo+Pg0KPj4gW01heSAy
NSAyMDA3XSBBSSBNYXR0aGV3IEFkYW1zIHByZXBh
cmUgYSBwcm9wb3NhbCB3aXRoIGp1c3QgdGhl
ICBiYXNpY3MNCj4+IG9mIHNjaGVtYSBzeW5jaHJv
bml6YXRpb24gd2l0aCBqZG8gYW5kIG9ybSBt
ZXRhZGF0YS4NCj4+DQo+PiBbTWF5IDE4IDIwMDdd
IEFJIENyYWlnIHVwZGF0ZSBodHRwOi8vd2lr
aS5hcGFjaGUub3JnL2pkby8NCj4+IEN1cnJlbnRE
ZXZlbG9wbWVudCB3aWtpIHBhZ2UNCj4+DQo+
PiBbQXByIDI3IDIwMDddIEFJIENyYWlnIHJldmll
dyBRdWVyeSBBUEkgYW5kIHNlbmQgZW1haWwg
dG8gZXhwZXJ0cy4NCj4+DQo+PiBbQXByIDI3IDIw
MDddIEFJIEVyaWsgZmlsZSBhIEpJUkEgcmVn
YXJkaW5nIEpQQSBzdHlsZSB0cmFuc2FjdGlvbnMg
IGFuZA0KPj4gYXR0YWNoIGhpcyBkaXNjdXNz
aW9uIGRvY3VtZW50IHRvIGl0Lg0KPj4NCj4+IFtN
YXIgOSAyMDA3XSBBSSBDcmFpZzogVXBkYXRl
IHRoZSBzcGVjIHRvIHJlcXVpcmUgdGhhdCB0aGUg
a2V5IG9mIHRoZQ0KPj4gbGlzdGVuZXIgaXMg
dGhlIGNsYXNzIG5hbWUgb2YgdGhlIGxpc3RlbmVy
LCBmb3IgY29uc2lzdGVuY3kgd2l0aA0KPj4g
cHJvcG9zZWQgeG1sLi4NCj4+DQo+PiBbTWFyIDIg
MjAwN10gQUkgQ3JhaWc6IHVwZGF0ZSB0aGUg
SkRPSGVscGVyIGNsYXNzIHRvIGluY2x1ZGUgYSBz
dHJpbmcNCj4+IGNvbnN0YW50ICJNRVRBLUlO
Ri9qZG8ueG1sIiBhbmQgYSBuZXcgbWV0aG9kDQo+
PiBnZXRQZXJzaXN0ZW5jZU1hbmFnZXJGYWN0
b3J5IHRha2luZyBubyBhcmd1bWVudHMuDQo+Pg0K
Pj4gW0F1ZyAxMSAyMDA2XSBBSSBDcmFpZyBw
cm9wb3NlIHNvbWUgc2VtYW50aWNzIGZvciBiZWhh
dmlvciBpZiB1c2VyDQo+PiB0cmllcyB0byBh
ZGQgdG8gYSBsaXN0IHdoZXJlIHRoZSBvcmRlcmlu
ZyBlbGVtZW50IGlzIGluY29ycmVjdC4NCj4+
DQo+PiBbSnVsIDE0IDIwMDZdIEFJOiBFcmlrIGRv
Y3VtZW50IDIyMCBhbm5vdGF0aW9ucyB0aGF0
IGRvbid0IGhhdmUgYQ0KPj4gY29ycmVzcG9uZGlu
ZyBKRE8gY29uY2VwdC4NCj4+DQo+PiBbSnVu
IDIzIDIwMDZdICBBSSAgTWFydGluIGxvb2sgYXQg
d2hhdCBIaWJlcm5hdGUgYW5kIFRvcExpbmsg
c3VwcG9ydA0KPj4gZm9yIEVudW0gdHlwZXMuIElu
IHByb2dyZXNzLg0KPj4NCj4+IFtBcHIgMTQg
MjAwNl0gQUkgQ3JhaWc6IHVwZGF0ZSB0aGUgcm9h
ZG1hcCBmb3IgSkRPLiBJbiBwcm9ncmVzcy4N
Cj4+DQo+PiBbTm92IDQgMjAwNV0gQUkgTWFydGlu
OiBVcGRhdGUgTWFydGluJ3Mgd2lraSB3aXRo
IGRpc2N1c2lvbiBvZiBKREsgICAxLjUNCj4+IGlz
c3Vlcy4gSW4gcHJvZ3Jlc3MNCj4+DQo+PiBb
U2VwIDIgMjAwNV0gQUk6IFRvIHJlY3J1aXQgbWVt
YmVycywgdXBkYXRlIHRoZSB3ZWIgc2l0ZS4g
QXJ0aWNsZXMgIG9uDQo+PiBUaGVTZXJ2ZXJTaWRl
IGRpcmVjdGluZyBhdHRlbnRpb24gdG8gdGhl
IHNpdGUuIFQtc2hpcnRzLCBsb2dvLiAgICBBSToN
Cj4+IENyYWlnIHdyaXRlIGEgU2VydmVyU2lk
ZSBhcnRpY2xlLg0KPj4NCj4+IC0tIE1pY2hlbGxl
DQo+Pg0KPj4gICAgIA0KPg0KPg0KPg0KPg0K
Pg0KPiAgIA0KDQoNCg==
|
|
|
|
|