You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Rick Curtis (JIRA)" <ji...@apache.org> on 2010/06/11 00:02:17 UTC
[jira] Created: (OPENJPA-1692) Add post creation callback to
BrokerFactory
Add post creation callback to BrokerFactory
-------------------------------------------
Key: OPENJPA-1692
URL: https://issues.apache.org/jira/browse/OPENJPA-1692
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 2.0.0, 2.1.0
Reporter: Rick Curtis
Assignee: Rick Curtis
There have been a couple instances (that come to my mind) where there was the need to do some work after creating the broker factory. Sometimes there is a necessity to ensure single threadedness @see (PersistenceProviderImpl.postBrokerFactoryInitialization(...)), other times we need to perform some additional configuration / initialization after the BrokerFactory has completed (openjpa.InitializeEagerly=true).
I recently ran across a problem with the second case. In AbstractBrokerFactory.ctor(...) we attempt to create a broker even though the subclassed BrokerFactory hasn't able to execute it's constructor.
Example pseudo code:
abstract class AbstractBrokerFactory {
AbstractBrokerFactory(Config c){
// setup
if(InitializeEagerly==true)
this.newBroker(); <-- BAD! The subclass hasn't executed it's constructor but it may be asked to create a new broker.
}
}
class ConcreteBrokerFactory extends AbstractBrokerFactory {
Config _conf;
ConcreteBrokerFactory (Config c){
super(c);
// setup
_conf = c;
}
newBroker(){
_conf.getSomething(); <-- _conf IS NULL because the constructor hasn't fully executed yet.
}
}
I propose that we need a postCreationCallBack method on the BrokerFactory interface. This will be a single place that Bootstrap can drive this 'after creation ish' work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-1692) Add post creation callback to
BrokerFactory
Posted by "Rick Curtis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Curtis closed OPENJPA-1692.
--------------------------------
Resolution: Fixed
Closing this JIRA as the original issue has been resolved. Will handle problem with the DataCacheManager initialization with OPENJPA-1705.
> Add post creation callback to BrokerFactory
> -------------------------------------------
>
> Key: OPENJPA-1692
> URL: https://issues.apache.org/jira/browse/OPENJPA-1692
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Rick Curtis
> Assignee: Rick Curtis
> Fix For: 2.1.0
>
>
> There have been a couple instances (that come to my mind) where there was the need to do some work after creating the broker factory. Sometimes there is a necessity to ensure single threadedness @see (PersistenceProviderImpl.postBrokerFactoryInitialization(...)), other times we need to perform some additional configuration / initialization after the BrokerFactory has completed (openjpa.InitializeEagerly=true).
> I recently ran across a problem with the second case. In AbstractBrokerFactory.ctor(...) we attempt to create a broker even though the subclassed BrokerFactory hasn't able to execute it's constructor.
> Example pseudo code:
> abstract class AbstractBrokerFactory {
> AbstractBrokerFactory(Config c){
> // setup
> if(InitializeEagerly==true)
> this.newBroker(); <-- BAD! The subclass hasn't executed it's constructor but it may be asked to create a new broker.
> }
> }
> class ConcreteBrokerFactory extends AbstractBrokerFactory {
> Config _conf;
> ConcreteBrokerFactory (Config c){
> super(c);
> // setup
> _conf = c;
> }
> newBroker(){
> _conf.getSomething(); <-- _conf IS NULL because the constructor hasn't fully executed yet.
> }
> }
> I propose that we need a postCreationCallBack method on the BrokerFactory interface. This will be a single place that Bootstrap can drive this 'after creation ish' work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-1692) Add post creation callback to
BrokerFactory
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877608#action_12877608 ]
Pinaki Poddar commented on OPENJPA-1692:
----------------------------------------
This is an useful suggestion. The other usage of such post-initialization method hooks can be leveraged to construct some critical internal data structures (e.g. MetaDataRepository) that are often immutable after initialization. One can initialize these structures with thread guards and then drop the guards for entire lifetime. This pattern will provide an opportunity to scale/perform faster in multi-core environment.
JPA does provide indicators such as <metadata-complete> etc to make such pattern.
> Add post creation callback to BrokerFactory
> -------------------------------------------
>
> Key: OPENJPA-1692
> URL: https://issues.apache.org/jira/browse/OPENJPA-1692
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Rick Curtis
> Assignee: Rick Curtis
>
> There have been a couple instances (that come to my mind) where there was the need to do some work after creating the broker factory. Sometimes there is a necessity to ensure single threadedness @see (PersistenceProviderImpl.postBrokerFactoryInitialization(...)), other times we need to perform some additional configuration / initialization after the BrokerFactory has completed (openjpa.InitializeEagerly=true).
> I recently ran across a problem with the second case. In AbstractBrokerFactory.ctor(...) we attempt to create a broker even though the subclassed BrokerFactory hasn't able to execute it's constructor.
> Example pseudo code:
> abstract class AbstractBrokerFactory {
> AbstractBrokerFactory(Config c){
> // setup
> if(InitializeEagerly==true)
> this.newBroker(); <-- BAD! The subclass hasn't executed it's constructor but it may be asked to create a new broker.
> }
> }
> class ConcreteBrokerFactory extends AbstractBrokerFactory {
> Config _conf;
> ConcreteBrokerFactory (Config c){
> super(c);
> // setup
> _conf = c;
> }
> newBroker(){
> _conf.getSomething(); <-- _conf IS NULL because the constructor hasn't fully executed yet.
> }
> }
> I propose that we need a postCreationCallBack method on the BrokerFactory interface. This will be a single place that Bootstrap can drive this 'after creation ish' work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OPENJPA-1692) Add post creation callback to
BrokerFactory
Posted by "Rick Curtis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Curtis reopened OPENJPA-1692:
----------------------------------
Reopening this issue while I investigate some test failures.
> Add post creation callback to BrokerFactory
> -------------------------------------------
>
> Key: OPENJPA-1692
> URL: https://issues.apache.org/jira/browse/OPENJPA-1692
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Rick Curtis
> Assignee: Rick Curtis
> Fix For: 2.1.0
>
>
> There have been a couple instances (that come to my mind) where there was the need to do some work after creating the broker factory. Sometimes there is a necessity to ensure single threadedness @see (PersistenceProviderImpl.postBrokerFactoryInitialization(...)), other times we need to perform some additional configuration / initialization after the BrokerFactory has completed (openjpa.InitializeEagerly=true).
> I recently ran across a problem with the second case. In AbstractBrokerFactory.ctor(...) we attempt to create a broker even though the subclassed BrokerFactory hasn't able to execute it's constructor.
> Example pseudo code:
> abstract class AbstractBrokerFactory {
> AbstractBrokerFactory(Config c){
> // setup
> if(InitializeEagerly==true)
> this.newBroker(); <-- BAD! The subclass hasn't executed it's constructor but it may be asked to create a new broker.
> }
> }
> class ConcreteBrokerFactory extends AbstractBrokerFactory {
> Config _conf;
> ConcreteBrokerFactory (Config c){
> super(c);
> // setup
> _conf = c;
> }
> newBroker(){
> _conf.getSomething(); <-- _conf IS NULL because the constructor hasn't fully executed yet.
> }
> }
> I propose that we need a postCreationCallBack method on the BrokerFactory interface. This will be a single place that Bootstrap can drive this 'after creation ish' work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-1692) Add post creation callback to
BrokerFactory
Posted by "Rick Curtis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Curtis updated OPENJPA-1692:
---------------------------------
Fix Version/s: 2.1.0
Update fix version.
> Add post creation callback to BrokerFactory
> -------------------------------------------
>
> Key: OPENJPA-1692
> URL: https://issues.apache.org/jira/browse/OPENJPA-1692
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Rick Curtis
> Assignee: Rick Curtis
> Fix For: 2.1.0
>
>
> There have been a couple instances (that come to my mind) where there was the need to do some work after creating the broker factory. Sometimes there is a necessity to ensure single threadedness @see (PersistenceProviderImpl.postBrokerFactoryInitialization(...)), other times we need to perform some additional configuration / initialization after the BrokerFactory has completed (openjpa.InitializeEagerly=true).
> I recently ran across a problem with the second case. In AbstractBrokerFactory.ctor(...) we attempt to create a broker even though the subclassed BrokerFactory hasn't able to execute it's constructor.
> Example pseudo code:
> abstract class AbstractBrokerFactory {
> AbstractBrokerFactory(Config c){
> // setup
> if(InitializeEagerly==true)
> this.newBroker(); <-- BAD! The subclass hasn't executed it's constructor but it may be asked to create a new broker.
> }
> }
> class ConcreteBrokerFactory extends AbstractBrokerFactory {
> Config _conf;
> ConcreteBrokerFactory (Config c){
> super(c);
> // setup
> _conf = c;
> }
> newBroker(){
> _conf.getSomething(); <-- _conf IS NULL because the constructor hasn't fully executed yet.
> }
> }
> I propose that we need a postCreationCallBack method on the BrokerFactory interface. This will be a single place that Bootstrap can drive this 'after creation ish' work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-1692) Add post creation callback to
BrokerFactory
Posted by "Rick Curtis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877931#action_12877931 ]
Rick Curtis commented on OPENJPA-1692:
--------------------------------------
@Pinaki -- Great point, but I want to keep this JIRA focused on properly designing the infrastructure for post creation callbacks and moving existing dependent code.
I opened OPENJPA-1694 as a defect for us to be more intelligent about when we can eagerly load metadata. Perhaps when doing this work we will discover that there are other cases where it makes sense to remove some of the laziness of OpenJPA for the sake of scalability.
> Add post creation callback to BrokerFactory
> -------------------------------------------
>
> Key: OPENJPA-1692
> URL: https://issues.apache.org/jira/browse/OPENJPA-1692
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Rick Curtis
> Assignee: Rick Curtis
> Fix For: 2.1.0
>
>
> There have been a couple instances (that come to my mind) where there was the need to do some work after creating the broker factory. Sometimes there is a necessity to ensure single threadedness @see (PersistenceProviderImpl.postBrokerFactoryInitialization(...)), other times we need to perform some additional configuration / initialization after the BrokerFactory has completed (openjpa.InitializeEagerly=true).
> I recently ran across a problem with the second case. In AbstractBrokerFactory.ctor(...) we attempt to create a broker even though the subclassed BrokerFactory hasn't able to execute it's constructor.
> Example pseudo code:
> abstract class AbstractBrokerFactory {
> AbstractBrokerFactory(Config c){
> // setup
> if(InitializeEagerly==true)
> this.newBroker(); <-- BAD! The subclass hasn't executed it's constructor but it may be asked to create a new broker.
> }
> }
> class ConcreteBrokerFactory extends AbstractBrokerFactory {
> Config _conf;
> ConcreteBrokerFactory (Config c){
> super(c);
> // setup
> _conf = c;
> }
> newBroker(){
> _conf.getSomething(); <-- _conf IS NULL because the constructor hasn't fully executed yet.
> }
> }
> I propose that we need a postCreationCallBack method on the BrokerFactory interface. This will be a single place that Bootstrap can drive this 'after creation ish' work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-1692) Add post creation callback to
BrokerFactory
Posted by "Rick Curtis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877883#action_12877883 ]
Rick Curtis commented on OPENJPA-1692:
--------------------------------------
My previous commit will regress OPENJPA-1491. Refactoring some code right now to take that problem into account.
> Add post creation callback to BrokerFactory
> -------------------------------------------
>
> Key: OPENJPA-1692
> URL: https://issues.apache.org/jira/browse/OPENJPA-1692
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Rick Curtis
> Assignee: Rick Curtis
>
> There have been a couple instances (that come to my mind) where there was the need to do some work after creating the broker factory. Sometimes there is a necessity to ensure single threadedness @see (PersistenceProviderImpl.postBrokerFactoryInitialization(...)), other times we need to perform some additional configuration / initialization after the BrokerFactory has completed (openjpa.InitializeEagerly=true).
> I recently ran across a problem with the second case. In AbstractBrokerFactory.ctor(...) we attempt to create a broker even though the subclassed BrokerFactory hasn't able to execute it's constructor.
> Example pseudo code:
> abstract class AbstractBrokerFactory {
> AbstractBrokerFactory(Config c){
> // setup
> if(InitializeEagerly==true)
> this.newBroker(); <-- BAD! The subclass hasn't executed it's constructor but it may be asked to create a new broker.
> }
> }
> class ConcreteBrokerFactory extends AbstractBrokerFactory {
> Config _conf;
> ConcreteBrokerFactory (Config c){
> super(c);
> // setup
> _conf = c;
> }
> newBroker(){
> _conf.getSomething(); <-- _conf IS NULL because the constructor hasn't fully executed yet.
> }
> }
> I propose that we need a postCreationCallBack method on the BrokerFactory interface. This will be a single place that Bootstrap can drive this 'after creation ish' work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-1692) Add post creation callback to
BrokerFactory
Posted by "Rick Curtis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Curtis resolved OPENJPA-1692.
----------------------------------
Resolution: Fixed
> Add post creation callback to BrokerFactory
> -------------------------------------------
>
> Key: OPENJPA-1692
> URL: https://issues.apache.org/jira/browse/OPENJPA-1692
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Rick Curtis
> Assignee: Rick Curtis
> Fix For: 2.1.0
>
>
> There have been a couple instances (that come to my mind) where there was the need to do some work after creating the broker factory. Sometimes there is a necessity to ensure single threadedness @see (PersistenceProviderImpl.postBrokerFactoryInitialization(...)), other times we need to perform some additional configuration / initialization after the BrokerFactory has completed (openjpa.InitializeEagerly=true).
> I recently ran across a problem with the second case. In AbstractBrokerFactory.ctor(...) we attempt to create a broker even though the subclassed BrokerFactory hasn't able to execute it's constructor.
> Example pseudo code:
> abstract class AbstractBrokerFactory {
> AbstractBrokerFactory(Config c){
> // setup
> if(InitializeEagerly==true)
> this.newBroker(); <-- BAD! The subclass hasn't executed it's constructor but it may be asked to create a new broker.
> }
> }
> class ConcreteBrokerFactory extends AbstractBrokerFactory {
> Config _conf;
> ConcreteBrokerFactory (Config c){
> super(c);
> // setup
> _conf = c;
> }
> newBroker(){
> _conf.getSomething(); <-- _conf IS NULL because the constructor hasn't fully executed yet.
> }
> }
> I propose that we need a postCreationCallBack method on the BrokerFactory interface. This will be a single place that Bootstrap can drive this 'after creation ish' work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.