You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Pinaki Poddar (JIRA)" <ji...@apache.org> on 2007/08/02 21:53:52 UTC
[jira] Created: (OPENJPA-305) Dynamic configuration of
EntityManagerFactory
Dynamic configuration of EntityManagerFactory
---------------------------------------------
Key: OPENJPA-305
URL: https://issues.apache.org/jira/browse/OPENJPA-305
Project: OpenJPA
Issue Type: New Feature
Reporter: Pinaki Poddar
OpenJPA configures EntityManagerFactory at creation time via an instance of Configuartion object. Once EntityManagerFactory is created and a EntityManager is issued from it -- the Configuration is frozen by design. That is no further changes to Configuration is allowed as long as EntityManagerFactory lives.
For certain configuration properties, it is desirable to change them during the lifetime of a EntityManagerFactory.
This issue is raised to initiate a discussion on such a feature, the possibility and limitations of dynamic update and track the impact of such a change as frozen Configuration is an important assumption.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (OPENJPA-305) Dynamic configuration of EntityManagerFactory
Posted by Patrick Linskey <pl...@gmail.com>.
IIRC, we went to properties just for legacy reasons.
I would not be surprised if the new restrictions about null values are
causing these problems. Regardless, it sounds like this bears
investigation, rather than re-writing either the test case.
I would start by investigating what happens if you maintain a boolean
to record whether or not a value has been set, rather than overriding
the meaning of null.
-Patrick
On 9/19/07, Pinaki Poddar <pp...@bea.com> wrote:
> The test that broke (TestConfigurationImpl) defined a Configuration
> implementation Ctest.
> None of the Values of CTest is dynamic. CTest is not frozen.
> The test
> i. sets Values of C
> ii. serializes-deserializes C to C'
> iii. Compares C and C' (passes)
> iv. updates values of C'
> v. serializes-deserializes C' to C''
> vi. Compares C' and C'' (fails)
>
> I have not debugged it further to see why it breaks.
> My initial guess is our assumption of 'original value' being null is
> violated for C' which is deserialized version of C.
> Keeping the distinction for dynamic Values using 'original' while
> non-dynamic Values using 'current' strings makes the test pass (in a
> easy-way-out sort of way) because none of the Values is dynamic.
>
> I will debug it (may not be today though) to find out further.
>
> In fact, I think a crtical unanswered question about all this changes I
> have made is:
> Why Configuration was transposed to Properties for equality/hashCode
> computation?
>
>
> Given that we are acting (tweaking?) with incomplete knowledge on a
> stable Value framework, I suggest we keep the distiction based on
> dynamic nature of Values as that way we will not at least hamper
> non-dynamic Values.
>
>
> Pinaki Poddar
> 972.834.2865
>
>
> >-----Original Message-----
> >From: Patrick Linskey [mailto:plinskey@gmail.com]
> >Sent: Wednesday, September 19, 2007 2:14 AM
> >To: dev@openjpa.apache.org
> >Subject: Re: [jira] Commented: (OPENJPA-305) Dynamic
> >configuration of EntityManagerFactory
> >
> >Can you elaborate on this?
> >
> >Not knowing anything else about the situation, my instinct is
> >that a) is a better solution, since it seems like a better
> >architecture for the future.
> >
> >-Patrick
> >
> >On 9/18/07, Pinaki Poddar <pp...@bea.com> wrote:
> >> >>I don't understand why we do the isDynamic() check in equals() and
> >> >>hashCode(), though; shouldn't getOriginalValue() always be correct?
> >> >
> >> >Correct. Thanks.
> >>
> >> But one test openjpa.lib.conf.test.TestConfigurationImpl breaks
> >> because it uses a different Configuration impl.
> >> Either we a) modify the test or we b) retain the distinction between
> >> original and current value.
> >> I went for (b).
> >>
> >>
> >>
> >>
> >> Pinaki Poddar
> >> 972.834.2865
> >>
> >>
> >> >-----Original Message-----
> >> >From: Pinaki Poddar [mailto:ppoddar@bea.com]
> >> >Sent: Tuesday, September 18, 2007 9:09 PM
> >> >To: dev@openjpa.apache.org
> >> >Subject: RE: [jira] Commented: (OPENJPA-305) Dynamic
> >configuration of
> >> >EntityManagerFactory
> >> >
> >> >
> >> >>I don't understand why we do the isDynamic() check in equals() and
> >> >>hashCode(), though; shouldn't getOriginalValue() always be correct?
> >> >
> >> >Correct. Thanks.
> >> >
> >> >Pinaki Poddar
> >> >972.834.2865
> >> >
> >> >
> >> >>-----Original Message-----
> >> >>From: Patrick Linskey (JIRA) [mailto:jira@apache.org]
> >> >>Sent: Tuesday, September 18, 2007 9:03 PM
> >> >>To: dev@openjpa.apache.org
> >> >>Subject: [jira] Commented: (OPENJPA-305) Dynamic configuration of
> >> >>EntityManagerFactory
> >> >>
> >> >>
> >> >> [
> >> >>https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atla
> >> >>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
> >> >>_12528633 ]
> >> >>
> >> >>Patrick Linskey commented on OPENJPA-305:
> >> >>-----------------------------------------
> >> >>
> >> >>Generally, it looks good. Some comments:
> >> >>
> >> >>I don't understand why we do the isDynamic() check in equals() and
> >> >>hashCode(), though; shouldn't getOriginalValue() always be correct?
> >> >>
> >> >>Also, it looks like there's a synchronization issue at hand
> >> >-- based on
> >> >>my reading, dynamic sets must occur in a synchronized
> >manner, or the
> >> >>behavior is non-deterministic. That is OK (I don't think that we
> >> >>necessarily want to add synchronization on accesses), but
> >should be
> >> >>well-documented.
> >> >>
> >> >>> Dynamic configuration of EntityManagerFactory
> >> >>> ---------------------------------------------
> >> >>>
> >> >>> Key: OPENJPA-305
> >> >>> URL:
> >> >>https://issues.apache.org/jira/browse/OPENJPA-305
> >> >>> Project: OpenJPA
> >> >>> Issue Type: New Feature
> >> >>> Reporter: Pinaki Poddar
> >> >>> Attachments: openjpa-305.patch.1.txt
> >> >>>
> >> >>>
> >> >>> OpenJPA configures EntityManagerFactory at creation time via
> >> >>an instance of Configuartion object. Once EntityManagerFactory is
> >> >>created and a EntityManager is issued from it -- the Configuration
> >> >>is frozen by design. That is no further changes to
> >Configuration is
> >> >>allowed as long as EntityManagerFactory lives.
> >> >>> For certain configuration properties, it is desirable to
> >> >>change them during the lifetime of a EntityManagerFactory.
> >> >>> This issue is raised to initiate a discussion on such a
> >> >>feature, the possibility and limitations of dynamic update
> >and track
> >> >>the impact of such a change as frozen Configuration is an
> >important
> >> >>assumption.
> >> >>>
> >> >>
> >> >>--
> >> >>This message is automatically generated by JIRA.
> >> >>-
> >> >>You can reply to this email to add a comment to the issue online.
> >> >>
> >> >>
> >> >
> >> >Notice: This email message, together with any attachments, may
> >> >contain information of BEA Systems, Inc., its
> >subsidiaries and
> >> >affiliated entities, that may be confidential, proprietary,
> >> >copyrighted and/or legally privileged, and is intended solely for
> >> >the use of the individual or entity named in this message.
> >If you are
> >> >not the intended recipient, and have received this message
> >in error,
> >> >please immediately return this by email and then delete it.
> >> >
> >>
> >> Notice: This email message, together with any attachments,
> >may contain information of BEA Systems, Inc., its
> >subsidiaries and affiliated entities, that may be
> >confidential, proprietary, copyrighted and/or legally
> >privileged, and is intended solely for the use of the
> >individual or entity named in this message. If you are not the
> >intended recipient, and have received this message in error,
> >please immediately return this by email and then delete it.
> >>
> >
> >
> >--
> >Patrick Linskey
> >202 669 5907
> >
>
> Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
>
--
Patrick Linskey
202 669 5907
RE: [jira] Commented: (OPENJPA-305) Dynamic configuration of EntityManagerFactory
Posted by Pinaki Poddar <pp...@bea.com>.
The test that broke (TestConfigurationImpl) defined a Configuration
implementation Ctest.
None of the Values of CTest is dynamic. CTest is not frozen.
The test
i. sets Values of C
ii. serializes-deserializes C to C'
iii. Compares C and C' (passes)
iv. updates values of C'
v. serializes-deserializes C' to C''
vi. Compares C' and C'' (fails)
I have not debugged it further to see why it breaks.
My initial guess is our assumption of 'original value' being null is
violated for C' which is deserialized version of C.
Keeping the distinction for dynamic Values using 'original' while
non-dynamic Values using 'current' strings makes the test pass (in a
easy-way-out sort of way) because none of the Values is dynamic.
I will debug it (may not be today though) to find out further.
In fact, I think a crtical unanswered question about all this changes I
have made is:
Why Configuration was transposed to Properties for equality/hashCode
computation?
Given that we are acting (tweaking?) with incomplete knowledge on a
stable Value framework, I suggest we keep the distiction based on
dynamic nature of Values as that way we will not at least hamper
non-dynamic Values.
Pinaki Poddar
972.834.2865
>-----Original Message-----
>From: Patrick Linskey [mailto:plinskey@gmail.com]
>Sent: Wednesday, September 19, 2007 2:14 AM
>To: dev@openjpa.apache.org
>Subject: Re: [jira] Commented: (OPENJPA-305) Dynamic
>configuration of EntityManagerFactory
>
>Can you elaborate on this?
>
>Not knowing anything else about the situation, my instinct is
>that a) is a better solution, since it seems like a better
>architecture for the future.
>
>-Patrick
>
>On 9/18/07, Pinaki Poddar <pp...@bea.com> wrote:
>> >>I don't understand why we do the isDynamic() check in equals() and
>> >>hashCode(), though; shouldn't getOriginalValue() always be correct?
>> >
>> >Correct. Thanks.
>>
>> But one test openjpa.lib.conf.test.TestConfigurationImpl breaks
>> because it uses a different Configuration impl.
>> Either we a) modify the test or we b) retain the distinction between
>> original and current value.
>> I went for (b).
>>
>>
>>
>>
>> Pinaki Poddar
>> 972.834.2865
>>
>>
>> >-----Original Message-----
>> >From: Pinaki Poddar [mailto:ppoddar@bea.com]
>> >Sent: Tuesday, September 18, 2007 9:09 PM
>> >To: dev@openjpa.apache.org
>> >Subject: RE: [jira] Commented: (OPENJPA-305) Dynamic
>configuration of
>> >EntityManagerFactory
>> >
>> >
>> >>I don't understand why we do the isDynamic() check in equals() and
>> >>hashCode(), though; shouldn't getOriginalValue() always be correct?
>> >
>> >Correct. Thanks.
>> >
>> >Pinaki Poddar
>> >972.834.2865
>> >
>> >
>> >>-----Original Message-----
>> >>From: Patrick Linskey (JIRA) [mailto:jira@apache.org]
>> >>Sent: Tuesday, September 18, 2007 9:03 PM
>> >>To: dev@openjpa.apache.org
>> >>Subject: [jira] Commented: (OPENJPA-305) Dynamic configuration of
>> >>EntityManagerFactory
>> >>
>> >>
>> >> [
>> >>https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atla
>> >>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
>> >>_12528633 ]
>> >>
>> >>Patrick Linskey commented on OPENJPA-305:
>> >>-----------------------------------------
>> >>
>> >>Generally, it looks good. Some comments:
>> >>
>> >>I don't understand why we do the isDynamic() check in equals() and
>> >>hashCode(), though; shouldn't getOriginalValue() always be correct?
>> >>
>> >>Also, it looks like there's a synchronization issue at hand
>> >-- based on
>> >>my reading, dynamic sets must occur in a synchronized
>manner, or the
>> >>behavior is non-deterministic. That is OK (I don't think that we
>> >>necessarily want to add synchronization on accesses), but
>should be
>> >>well-documented.
>> >>
>> >>> Dynamic configuration of EntityManagerFactory
>> >>> ---------------------------------------------
>> >>>
>> >>> Key: OPENJPA-305
>> >>> URL:
>> >>https://issues.apache.org/jira/browse/OPENJPA-305
>> >>> Project: OpenJPA
>> >>> Issue Type: New Feature
>> >>> Reporter: Pinaki Poddar
>> >>> Attachments: openjpa-305.patch.1.txt
>> >>>
>> >>>
>> >>> OpenJPA configures EntityManagerFactory at creation time via
>> >>an instance of Configuartion object. Once EntityManagerFactory is
>> >>created and a EntityManager is issued from it -- the Configuration
>> >>is frozen by design. That is no further changes to
>Configuration is
>> >>allowed as long as EntityManagerFactory lives.
>> >>> For certain configuration properties, it is desirable to
>> >>change them during the lifetime of a EntityManagerFactory.
>> >>> This issue is raised to initiate a discussion on such a
>> >>feature, the possibility and limitations of dynamic update
>and track
>> >>the impact of such a change as frozen Configuration is an
>important
>> >>assumption.
>> >>>
>> >>
>> >>--
>> >>This message is automatically generated by JIRA.
>> >>-
>> >>You can reply to this email to add a comment to the issue online.
>> >>
>> >>
>> >
>> >Notice: This email message, together with any attachments, may
>> >contain information of BEA Systems, Inc., its
>subsidiaries and
>> >affiliated entities, that may be confidential, proprietary,
>> >copyrighted and/or legally privileged, and is intended solely for
>> >the use of the individual or entity named in this message.
>If you are
>> >not the intended recipient, and have received this message
>in error,
>> >please immediately return this by email and then delete it.
>> >
>>
>> Notice: This email message, together with any attachments,
>may contain information of BEA Systems, Inc., its
>subsidiaries and affiliated entities, that may be
>confidential, proprietary, copyrighted and/or legally
>privileged, and is intended solely for the use of the
>individual or entity named in this message. If you are not the
>intended recipient, and have received this message in error,
>please immediately return this by email and then delete it.
>>
>
>
>--
>Patrick Linskey
>202 669 5907
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [jira] Commented: (OPENJPA-305) Dynamic configuration of EntityManagerFactory
Posted by Patrick Linskey <pl...@gmail.com>.
Can you elaborate on this?
Not knowing anything else about the situation, my instinct is that a)
is a better solution, since it seems like a better architecture for
the future.
-Patrick
On 9/18/07, Pinaki Poddar <pp...@bea.com> wrote:
> >>I don't understand why we do the isDynamic() check in equals() and
> >>hashCode(), though; shouldn't getOriginalValue() always be correct?
> >
> >Correct. Thanks.
>
> But one test openjpa.lib.conf.test.TestConfigurationImpl breaks because
> it uses a different Configuration impl.
> Either we a) modify the test or we b) retain the distinction between
> original and current value.
> I went for (b).
>
>
>
>
> Pinaki Poddar
> 972.834.2865
>
>
> >-----Original Message-----
> >From: Pinaki Poddar [mailto:ppoddar@bea.com]
> >Sent: Tuesday, September 18, 2007 9:09 PM
> >To: dev@openjpa.apache.org
> >Subject: RE: [jira] Commented: (OPENJPA-305) Dynamic
> >configuration of EntityManagerFactory
> >
> >
> >>I don't understand why we do the isDynamic() check in equals() and
> >>hashCode(), though; shouldn't getOriginalValue() always be correct?
> >
> >Correct. Thanks.
> >
> >Pinaki Poddar
> >972.834.2865
> >
> >
> >>-----Original Message-----
> >>From: Patrick Linskey (JIRA) [mailto:jira@apache.org]
> >>Sent: Tuesday, September 18, 2007 9:03 PM
> >>To: dev@openjpa.apache.org
> >>Subject: [jira] Commented: (OPENJPA-305) Dynamic configuration of
> >>EntityManagerFactory
> >>
> >>
> >> [
> >>https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atla
> >>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
> >>_12528633 ]
> >>
> >>Patrick Linskey commented on OPENJPA-305:
> >>-----------------------------------------
> >>
> >>Generally, it looks good. Some comments:
> >>
> >>I don't understand why we do the isDynamic() check in equals() and
> >>hashCode(), though; shouldn't getOriginalValue() always be correct?
> >>
> >>Also, it looks like there's a synchronization issue at hand
> >-- based on
> >>my reading, dynamic sets must occur in a synchronized manner, or the
> >>behavior is non-deterministic. That is OK (I don't think that we
> >>necessarily want to add synchronization on accesses), but should be
> >>well-documented.
> >>
> >>> Dynamic configuration of EntityManagerFactory
> >>> ---------------------------------------------
> >>>
> >>> Key: OPENJPA-305
> >>> URL:
> >>https://issues.apache.org/jira/browse/OPENJPA-305
> >>> Project: OpenJPA
> >>> Issue Type: New Feature
> >>> Reporter: Pinaki Poddar
> >>> Attachments: openjpa-305.patch.1.txt
> >>>
> >>>
> >>> OpenJPA configures EntityManagerFactory at creation time via
> >>an instance of Configuartion object. Once EntityManagerFactory is
> >>created and a EntityManager is issued from it -- the Configuration is
> >>frozen by design. That is no further changes to Configuration is
> >>allowed as long as EntityManagerFactory lives.
> >>> For certain configuration properties, it is desirable to
> >>change them during the lifetime of a EntityManagerFactory.
> >>> This issue is raised to initiate a discussion on such a
> >>feature, the possibility and limitations of dynamic update and track
> >>the impact of such a change as frozen Configuration is an important
> >>assumption.
> >>>
> >>
> >>--
> >>This message is automatically generated by JIRA.
> >>-
> >>You can reply to this email to add a comment to the issue online.
> >>
> >>
> >
> >Notice: This email message, together with any attachments,
> >may contain information of BEA Systems, Inc., its
> >subsidiaries and affiliated entities, that may be
> >confidential, proprietary, copyrighted and/or legally
> >privileged, and is intended solely for the use of the
> >individual or entity named in this message. If you are not the
> >intended recipient, and have received this message in error,
> >please immediately return this by email and then delete it.
> >
>
> Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
>
--
Patrick Linskey
202 669 5907
RE: [jira] Commented: (OPENJPA-305) Dynamic configuration of EntityManagerFactory
Posted by Pinaki Poddar <pp...@bea.com>.
>>I don't understand why we do the isDynamic() check in equals() and
>>hashCode(), though; shouldn't getOriginalValue() always be correct?
>
>Correct. Thanks.
But one test openjpa.lib.conf.test.TestConfigurationImpl breaks because
it uses a different Configuration impl.
Either we a) modify the test or we b) retain the distinction between
original and current value.
I went for (b).
Pinaki Poddar
972.834.2865
>-----Original Message-----
>From: Pinaki Poddar [mailto:ppoddar@bea.com]
>Sent: Tuesday, September 18, 2007 9:09 PM
>To: dev@openjpa.apache.org
>Subject: RE: [jira] Commented: (OPENJPA-305) Dynamic
>configuration of EntityManagerFactory
>
>
>>I don't understand why we do the isDynamic() check in equals() and
>>hashCode(), though; shouldn't getOriginalValue() always be correct?
>
>Correct. Thanks.
>
>Pinaki Poddar
>972.834.2865
>
>
>>-----Original Message-----
>>From: Patrick Linskey (JIRA) [mailto:jira@apache.org]
>>Sent: Tuesday, September 18, 2007 9:03 PM
>>To: dev@openjpa.apache.org
>>Subject: [jira] Commented: (OPENJPA-305) Dynamic configuration of
>>EntityManagerFactory
>>
>>
>> [
>>https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atla
>>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
>>_12528633 ]
>>
>>Patrick Linskey commented on OPENJPA-305:
>>-----------------------------------------
>>
>>Generally, it looks good. Some comments:
>>
>>I don't understand why we do the isDynamic() check in equals() and
>>hashCode(), though; shouldn't getOriginalValue() always be correct?
>>
>>Also, it looks like there's a synchronization issue at hand
>-- based on
>>my reading, dynamic sets must occur in a synchronized manner, or the
>>behavior is non-deterministic. That is OK (I don't think that we
>>necessarily want to add synchronization on accesses), but should be
>>well-documented.
>>
>>> Dynamic configuration of EntityManagerFactory
>>> ---------------------------------------------
>>>
>>> Key: OPENJPA-305
>>> URL:
>>https://issues.apache.org/jira/browse/OPENJPA-305
>>> Project: OpenJPA
>>> Issue Type: New Feature
>>> Reporter: Pinaki Poddar
>>> Attachments: openjpa-305.patch.1.txt
>>>
>>>
>>> OpenJPA configures EntityManagerFactory at creation time via
>>an instance of Configuartion object. Once EntityManagerFactory is
>>created and a EntityManager is issued from it -- the Configuration is
>>frozen by design. That is no further changes to Configuration is
>>allowed as long as EntityManagerFactory lives.
>>> For certain configuration properties, it is desirable to
>>change them during the lifetime of a EntityManagerFactory.
>>> This issue is raised to initiate a discussion on such a
>>feature, the possibility and limitations of dynamic update and track
>>the impact of such a change as frozen Configuration is an important
>>assumption.
>>>
>>
>>--
>>This message is automatically generated by JIRA.
>>-
>>You can reply to this email to add a comment to the issue online.
>>
>>
>
>Notice: This email message, together with any attachments,
>may contain information of BEA Systems, Inc., its
>subsidiaries and affiliated entities, that may be
>confidential, proprietary, copyrighted and/or legally
>privileged, and is intended solely for the use of the
>individual or entity named in this message. If you are not the
>intended recipient, and have received this message in error,
>please immediately return this by email and then delete it.
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: [jira] Commented: (OPENJPA-305) Dynamic configuration of EntityManagerFactory
Posted by Pinaki Poddar <pp...@bea.com>.
>I don't understand why we do the isDynamic() check in equals()
>and hashCode(), though; shouldn't getOriginalValue() always be correct?
Correct. Thanks.
Pinaki Poddar
972.834.2865
>-----Original Message-----
>From: Patrick Linskey (JIRA) [mailto:jira@apache.org]
>Sent: Tuesday, September 18, 2007 9:03 PM
>To: dev@openjpa.apache.org
>Subject: [jira] Commented: (OPENJPA-305) Dynamic configuration
>of EntityManagerFactory
>
>
> [
>https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atla
>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
>_12528633 ]
>
>Patrick Linskey commented on OPENJPA-305:
>-----------------------------------------
>
>Generally, it looks good. Some comments:
>
>I don't understand why we do the isDynamic() check in equals()
>and hashCode(), though; shouldn't getOriginalValue() always be correct?
>
>Also, it looks like there's a synchronization issue at hand --
>based on my reading, dynamic sets must occur in a synchronized
>manner, or the behavior is non-deterministic. That is OK (I
>don't think that we necessarily want to add synchronization on
>accesses), but should be well-documented.
>
>> Dynamic configuration of EntityManagerFactory
>> ---------------------------------------------
>>
>> Key: OPENJPA-305
>> URL:
>https://issues.apache.org/jira/browse/OPENJPA-305
>> Project: OpenJPA
>> Issue Type: New Feature
>> Reporter: Pinaki Poddar
>> Attachments: openjpa-305.patch.1.txt
>>
>>
>> OpenJPA configures EntityManagerFactory at creation time via
>an instance of Configuartion object. Once EntityManagerFactory
>is created and a EntityManager is issued from it -- the
>Configuration is frozen by design. That is no further changes
>to Configuration is allowed as long as EntityManagerFactory lives.
>> For certain configuration properties, it is desirable to
>change them during the lifetime of a EntityManagerFactory.
>> This issue is raised to initiate a discussion on such a
>feature, the possibility and limitations of dynamic update and
>track the impact of such a change as frozen Configuration is
>an important assumption.
>>
>
>--
>This message is automatically generated by JIRA.
>-
>You can reply to this email to add a comment to the issue online.
>
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: [jira] Commented: (OPENJPA-305) Dynamic configuration of EntityManagerFactory
Posted by Pinaki Poddar <pp...@bea.com>.
> 4. ConfigurationImpl used to compute its hashCode() and equals() by
first converting itself into a Properties object.
> I do not why.
Some pointers on why converting to Properties before equals/hashCode?
Pinaki Poddar
972.834.2865
>-----Original Message-----
>From: Patrick Linskey (JIRA) [mailto:jira@apache.org]
>Sent: Tuesday, September 18, 2007 9:03 PM
>To: dev@openjpa.apache.org
>Subject: [jira] Commented: (OPENJPA-305) Dynamic configuration
>of EntityManagerFactory
>
>
> [
>https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atla
>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
>_12528633 ]
>
>Patrick Linskey commented on OPENJPA-305:
>-----------------------------------------
>
>Generally, it looks good. Some comments:
>
>I don't understand why we do the isDynamic() check in equals()
>and hashCode(), though; shouldn't getOriginalValue() always be correct?
>
>Also, it looks like there's a synchronization issue at hand --
>based on my reading, dynamic sets must occur in a synchronized
>manner, or the behavior is non-deterministic. That is OK (I
>don't think that we necessarily want to add synchronization on
>accesses), but should be well-documented.
>
>> Dynamic configuration of EntityManagerFactory
>> ---------------------------------------------
>>
>> Key: OPENJPA-305
>> URL:
>https://issues.apache.org/jira/browse/OPENJPA-305
>> Project: OpenJPA
>> Issue Type: New Feature
>> Reporter: Pinaki Poddar
>> Attachments: openjpa-305.patch.1.txt
>>
>>
>> OpenJPA configures EntityManagerFactory at creation time via
>an instance of Configuartion object. Once EntityManagerFactory
>is created and a EntityManager is issued from it -- the
>Configuration is frozen by design. That is no further changes
>to Configuration is allowed as long as EntityManagerFactory lives.
>> For certain configuration properties, it is desirable to
>change them during the lifetime of a EntityManagerFactory.
>> This issue is raised to initiate a discussion on such a
>feature, the possibility and limitations of dynamic update and
>track the impact of such a change as frozen Configuration is
>an important assumption.
>>
>
>--
>This message is automatically generated by JIRA.
>-
>You can reply to this email to add a comment to the issue online.
>
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (OPENJPA-305) Dynamic configuration of
EntityManagerFactory
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528633 ]
Patrick Linskey commented on OPENJPA-305:
-----------------------------------------
Generally, it looks good. Some comments:
I don't understand why we do the isDynamic() check in equals() and hashCode(), though; shouldn't getOriginalValue() always be correct?
Also, it looks like there's a synchronization issue at hand -- based on my reading, dynamic sets must occur in a synchronized manner, or the behavior is non-deterministic. That is OK (I don't think that we necessarily want to add synchronization on accesses), but should be well-documented.
> Dynamic configuration of EntityManagerFactory
> ---------------------------------------------
>
> Key: OPENJPA-305
> URL: https://issues.apache.org/jira/browse/OPENJPA-305
> Project: OpenJPA
> Issue Type: New Feature
> Reporter: Pinaki Poddar
> Attachments: openjpa-305.patch.1.txt
>
>
> OpenJPA configures EntityManagerFactory at creation time via an instance of Configuartion object. Once EntityManagerFactory is created and a EntityManager is issued from it -- the Configuration is frozen by design. That is no further changes to Configuration is allowed as long as EntityManagerFactory lives.
> For certain configuration properties, it is desirable to change them during the lifetime of a EntityManagerFactory.
> This issue is raised to initiate a discussion on such a feature, the possibility and limitations of dynamic update and track the impact of such a change as frozen Configuration is an important assumption.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-305) Dynamic configuration of
EntityManagerFactory
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517415 ]
Pinaki Poddar commented on OPENJPA-305:
---------------------------------------
Dynamic (i.e. while EntityManagerFactory is alive) change of Configuration will impact the pooling of BrokerFactory (which is the core implementation of which EntityManagerFactory is a facade).
The pool maintains a Map of poolKey to BrokerFactory. A poolKey is effectively the Configuration expressed as a Property. So dynamically changing configuration properties must take into account the integrity of this pool which is till now based on the assumption of constancy of Configuration.
Possibility of using IdentityHashMap and use the Configuration instance (not its Property values) as key:
This is most likely *not* going to work. The idea of freezing the config at the first place (perhaps) originated because callers who supply new copies of Configuration (that are same by value but not by identity) expect to get the same Factory.
> Dynamic configuration of EntityManagerFactory
> ---------------------------------------------
>
> Key: OPENJPA-305
> URL: https://issues.apache.org/jira/browse/OPENJPA-305
> Project: OpenJPA
> Issue Type: New Feature
> Reporter: Pinaki Poddar
>
> OpenJPA configures EntityManagerFactory at creation time via an instance of Configuartion object. Once EntityManagerFactory is created and a EntityManager is issued from it -- the Configuration is frozen by design. That is no further changes to Configuration is allowed as long as EntityManagerFactory lives.
> For certain configuration properties, it is desirable to change them during the lifetime of a EntityManagerFactory.
> This issue is raised to initiate a discussion on such a feature, the possibility and limitations of dynamic update and track the impact of such a change as frozen Configuration is an important assumption.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-305) Dynamic configuration of
EntityManagerFactory
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517437 ]
Craig Russell commented on OPENJPA-305:
---------------------------------------
I agree with Patrick.
The intent of making the EMF not configurable after the first getEM is just so that you can find an EMF based on the user-defined values.
If you ask for an EMF that has a default property, and that property has changed, then you cannot get the behavior you expect.
> Dynamic configuration of EntityManagerFactory
> ---------------------------------------------
>
> Key: OPENJPA-305
> URL: https://issues.apache.org/jira/browse/OPENJPA-305
> Project: OpenJPA
> Issue Type: New Feature
> Reporter: Pinaki Poddar
>
> OpenJPA configures EntityManagerFactory at creation time via an instance of Configuartion object. Once EntityManagerFactory is created and a EntityManager is issued from it -- the Configuration is frozen by design. That is no further changes to Configuration is allowed as long as EntityManagerFactory lives.
> For certain configuration properties, it is desirable to change them during the lifetime of a EntityManagerFactory.
> This issue is raised to initiate a discussion on such a feature, the possibility and limitations of dynamic update and track the impact of such a change as frozen Configuration is an important assumption.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-305) Dynamic configuration of
EntityManagerFactory
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517419 ]
Patrick Linskey commented on OPENJPA-305:
-----------------------------------------
I think that the best approach is to make the key computation be based on the original values. That way, any lookups for a configuration with a given set of original values will route to the same (possibly-mutated) new values.
> Dynamic configuration of EntityManagerFactory
> ---------------------------------------------
>
> Key: OPENJPA-305
> URL: https://issues.apache.org/jira/browse/OPENJPA-305
> Project: OpenJPA
> Issue Type: New Feature
> Reporter: Pinaki Poddar
>
> OpenJPA configures EntityManagerFactory at creation time via an instance of Configuartion object. Once EntityManagerFactory is created and a EntityManager is issued from it -- the Configuration is frozen by design. That is no further changes to Configuration is allowed as long as EntityManagerFactory lives.
> For certain configuration properties, it is desirable to change them during the lifetime of a EntityManagerFactory.
> This issue is raised to initiate a discussion on such a feature, the possibility and limitations of dynamic update and track the impact of such a change as frozen Configuration is an important assumption.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-305) Dynamic configuration of
EntityManagerFactory
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pinaki Poddar resolved OPENJPA-305.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.1.0
1.2.0
Assignee: Pinaki Poddar
> Dynamic configuration of EntityManagerFactory
> ---------------------------------------------
>
> Key: OPENJPA-305
> URL: https://issues.apache.org/jira/browse/OPENJPA-305
> Project: OpenJPA
> Issue Type: New Feature
> Reporter: Pinaki Poddar
> Assignee: Pinaki Poddar
> Fix For: 1.2.0, 1.1.0
>
> Attachments: openjpa-305.patch.1.txt
>
>
> OpenJPA configures EntityManagerFactory at creation time via an instance of Configuartion object. Once EntityManagerFactory is created and a EntityManager is issued from it -- the Configuration is frozen by design. That is no further changes to Configuration is allowed as long as EntityManagerFactory lives.
> For certain configuration properties, it is desirable to change them during the lifetime of a EntityManagerFactory.
> This issue is raised to initiate a discussion on such a feature, the possibility and limitations of dynamic update and track the impact of such a change as frozen Configuration is an important assumption.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-305) Dynamic configuration of
EntityManagerFactory
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pinaki Poddar updated OPENJPA-305:
----------------------------------
Attachment: openjpa-305.patch.1.txt
This is a proposed patch that makes few significant changes in Value-Configuration part to support dynamic update of Configuration. Hence this is a patch for your comment/review.
1. The intents are
a) certain Values can be marked dynamic. This allows them to be modified even after the configuration is frozen i.e. EntityManagerFactory has issued its first EntityManager.
b) because EntityManagerFactories are cached based on the keys of their configuration, the hashCode of the configuration must not be changed when a dynamic value V changes from x1 to x2.
For example, for Configuration A, one of it's value V(A) is originally set to x1. Later it was modified to x2.
A.hashCode() should remain the same before and after the modification if V is dynamic.
c) Equality: Two Configuration A and B had originally V(A)=x and V(B)=y where V is dynamic.
Initially x!=y. That implies A not equals B.
Now V(B) is set to x. Does A now equals B?
The intended answer is no.
2. What needed to support (1c) is notion of 'originalValue' for dynamic properties. This patch implements by declaring a new String field in Value.class, also logic of setting this 'originalValue' in setString() and setObject() methods.
3. The 'originalValue' notion is used for changed behavior of Value.equals() and Value.hashCode() methods.
4. ConfigurationImpl used to compute its hashCode() and equals() by first converting itself into a Properties object. I do not why. That is the main reason this is submitted as a patch for everyone's comment/review.
This patch makes a conceptual change. Now ConfigurationImpl computes its hashCode() and equals() based on its Values -- who in turn evaluates their own hashCode() and equals() that varies based on their dynamic nature.
> Dynamic configuration of EntityManagerFactory
> ---------------------------------------------
>
> Key: OPENJPA-305
> URL: https://issues.apache.org/jira/browse/OPENJPA-305
> Project: OpenJPA
> Issue Type: New Feature
> Reporter: Pinaki Poddar
> Attachments: openjpa-305.patch.1.txt
>
>
> OpenJPA configures EntityManagerFactory at creation time via an instance of Configuartion object. Once EntityManagerFactory is created and a EntityManager is issued from it -- the Configuration is frozen by design. That is no further changes to Configuration is allowed as long as EntityManagerFactory lives.
> For certain configuration properties, it is desirable to change them during the lifetime of a EntityManagerFactory.
> This issue is raised to initiate a discussion on such a feature, the possibility and limitations of dynamic update and track the impact of such a change as frozen Configuration is an important assumption.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.