Re: Where to report bugs / contribue patches
Thanks, this works, anyone able to fix this on the OJB page? Oliver On Fri, 10 Dec 2004 18:31:41 +0100, Jakob Braeuchi <[EMAIL PROTECTED]> wrote: > hi oliver, > > the correct link is > http://nagoya.apache.org/scarab/servlet/scarab/ > > jakob > > Oliver Zeigermann schrieb: > > > > This link on the OJB page: > > > > http://issues.apache.org/scarab/servlet/scarab/ > > > > Does not exist... > > > > Oliver > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to report bugs / contribue patches
hi oliver, i fixed it in the sources for the site, but i can not update the site. jakob Oliver Zeigermann schrieb: Thanks, this works, anyone able to fix this on the OJB page? Oliver On Fri, 10 Dec 2004 18:31:41 +0100, Jakob Braeuchi <[EMAIL PROTECTED]> wrote: hi oliver, the correct link is http://nagoya.apache.org/scarab/servlet/scarab/ jakob Oliver Zeigermann schrieb: This link on the OJB page: http://issues.apache.org/scarab/servlet/scarab/ Does not exist... Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to access the current platfrom from BatchEntryImpl?
Thanks, will do. Oliver On Fri, 10 Dec 2004 19:24:51 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote: > Hi Oliver, > > I think this is currently not possible. But you working on OJB 1.1 so > changes are possible, e.g. declare a new protected > BatchManagerImpl#getPersistenceBroker() method and use in BatchEntryImpl > batchManager.getPersistenceBroker().getConnectionManager().getSupportedPlatform() > > regards, > Armin > > > > Oliver Zeigermann wrote: > > Subject says it all... > > > > Thanks, > > > > Oliver > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to access the current platfrom from BatchEntryImpl?
Hi Oliver, I think this is currently not possible. But you working on OJB 1.1 so changes are possible, e.g. declare a new protected BatchManagerImpl#getPersistenceBroker() method and use in BatchEntryImpl batchManager.getPersistenceBroker().getConnectionManager().getSupportedPlatform() regards, Armin Oliver Zeigermann wrote: Subject says it all... Thanks, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to access the current platfrom from BatchEntryImpl?
Subject says it all... Thanks, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to report bugs / contribue patches
hi oliver, the correct link is http://nagoya.apache.org/scarab/servlet/scarab/ jakob Oliver Zeigermann schrieb: This link on the OJB page: http://issues.apache.org/scarab/servlet/scarab/ Does not exist... Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where to report bugs / contribue patches
This link on the OJB page: http://issues.apache.org/scarab/servlet/scarab/ Does not exist... Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another implementation of the Two Level Cache
As you say ... to get higher isolations level I think you have to use blocking locks ... -Message d'origine- De: Oliver Zeigermann A: OJB Users List Date: 10/12/2004 17:27 Objet: Re: Another implementation of the Two Level Cache Yes, talking about Jakarta Slide. Do you know if it is possible to have higher isolations without using blocking locks or a scheme that might fail? It's impossible, isn't it? Oliver On Fri, 10 Dec 2004 17:22:50 +0100, CLARAMONTE Jean-Baptiste <[EMAIL PROTECTED]> wrote: > The Slide project ? which project are you talking about ? the one from > Jakarta ? > > Yes the resulting isolation level is similar to READ_COMMITED. > > -Message d'origine- > De: Oliver Zeigermann > A: OJB Users List > Date: 10/12/2004 14:53 > > > Objet: Re: Another implementation of the Two Level Cache > > This pretty much is the mechanism the Slide project uses. AFAIK the > isolation level is similar to READ_COMMITTED, isn't it? > > Oliver > > On Fri, 10 Dec 2004 13:18:53 +0100, CLARAMONTE Jean-Baptiste > <[EMAIL PROTECTED]> wrote: > > Hello, > > > > As I was not satisfy with the implementation of the TwoLevelCache, > > mainly because it was not isolating the object in use in a transaction > > with others transactions, so I've tried to write another one and now I > > would like too share it with the community. > > For resuming here are the behavior of this cache : > > When you retrieve an object a flat copy are made and the added in the > > > > first level cache (a kind of broker session cache). > > A call to store() will not immediately put the objet in the second > > level cache but only in the first level (so this way other > > transactions are isolated from update on the objet since your > > transaction could finally abort) > > Rollbacking a transaction simply clear the first level cache (the > > broker session cache) > > Commiting the transaction transfert the object from the first level > > cache to the second level cache so that object update become visible > > to other transactions. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > *** We scanned this email for malicious content *** > *** IMPORTANT: Do not open attachments from unrecognized senders *** > *** MailSystem ASTON *** > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** We scanned this email for malicious content *** *** IMPORTANT: Do not open attachments from unrecognized senders *** *** MailSystem ASTON *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another implementation of the Two Level Cache
Yes, talking about Jakarta Slide. Do you know if it is possible to have higher isolations without using blocking locks or a scheme that might fail? It's impossible, isn't it? Oliver On Fri, 10 Dec 2004 17:22:50 +0100, CLARAMONTE Jean-Baptiste <[EMAIL PROTECTED]> wrote: > The Slide project ? which project are you talking about ? the one from > Jakarta ? > > Yes the resulting isolation level is similar to READ_COMMITED. > > -Message d'origine- > De: Oliver Zeigermann > A: OJB Users List > Date: 10/12/2004 14:53 > > > Objet: Re: Another implementation of the Two Level Cache > > This pretty much is the mechanism the Slide project uses. AFAIK the > isolation level is similar to READ_COMMITTED, isn't it? > > Oliver > > On Fri, 10 Dec 2004 13:18:53 +0100, CLARAMONTE Jean-Baptiste > <[EMAIL PROTECTED]> wrote: > > Hello, > > > > As I was not satisfy with the implementation of the TwoLevelCache, > > mainly because it was not isolating the object in use in a transaction > > with others transactions, so I've tried to write another one and now I > > would like too share it with the community. > > For resuming here are the behavior of this cache : > > When you retrieve an object a flat copy are made and the added in the > > > > first level cache (a kind of broker session cache). > > A call to store() will not immediately put the objet in the second > > level cache but only in the first level (so this way other > > transactions are isolated from update on the objet since your > > transaction could finally abort) > > Rollbacking a transaction simply clear the first level cache (the > > broker session cache) > > Commiting the transaction transfert the object from the first level > > cache to the second level cache so that object update become visible > > to other transactions. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > *** We scanned this email for malicious content *** > *** IMPORTANT: Do not open attachments from unrecognized senders *** > *** MailSystem ASTON *** > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another implementation of the Two Level Cache
The Slide project ? which project are you talking about ? the one from Jakarta ? Yes the resulting isolation level is similar to READ_COMMITED. -Message d'origine- De: Oliver Zeigermann A: OJB Users List Date: 10/12/2004 14:53 Objet: Re: Another implementation of the Two Level Cache This pretty much is the mechanism the Slide project uses. AFAIK the isolation level is similar to READ_COMMITTED, isn't it? Oliver On Fri, 10 Dec 2004 13:18:53 +0100, CLARAMONTE Jean-Baptiste <[EMAIL PROTECTED]> wrote: > Hello, > > As I was not satisfy with the implementation of the TwoLevelCache, > mainly because it was not isolating the object in use in a transaction > with others transactions, so I've tried to write another one and now I > would like too share it with the community. > For resuming here are the behavior of this cache : > When you retrieve an object a flat copy are made and the added in the > first level cache (a kind of broker session cache). > A call to store() will not immediately put the objet in the second > level cache but only in the first level (so this way other > transactions are isolated from update on the objet since your > transaction could finally abort) > Rollbacking a transaction simply clear the first level cache (the > broker session cache) > Commiting the transaction transfert the object from the first level > cache to the second level cache so that object update become visible > to other transactions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** We scanned this email for malicious content *** *** IMPORTANT: Do not open attachments from unrecognized senders *** *** MailSystem ASTON *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another implementation of the Two Level Cache
go ahead ! I'm glad to contribute !
:-)
-Message d'origine-
De: Armin Waibel
A: OJB Users List
Date: 10/12/2004 16:14
Objet: Re: Another implementation of the Two Level Cache
Hi Jean-Baptiste,
CLARAMONTE Jean-Baptiste wrote:
> Hello,
>
> As I was not satisfy with the implementation of the TwoLevelCache,
> mainly because it was not isolating the object in use in a transaction
> with others transactions, so I've tried to write another one and now I
> would like too share it with the community.
thanks for contribution!
You are right, the TwoLevelCache in CVS is only a alpha-version for a
two-level caching (upcoming OJB 1.1 in CVS trunk will support a real
two-level cache) and I never test it.
> For resuming here are the behavior of this cache :
> When you retrieve an object a flat copy are made
Your copy based on bean properties - or I'm wrong? I recommend to use
the OJB metadata information (associated FieldDescriptor of the object)
to make the copy. Because user could use different PersistentField
implementations (e.g. standard beans, only fields no getter/setter, dyna
beans,..).
In OJB trunk I introduce a class called SnapshotBuilder (alpha version)
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/
cache/SnapshotBuilder.java?view=markup
To get a new object instance, please use
ClassHelper#buildNewObjectInstance
This method include user defined object factories.
> and the added in the
> first level cache (a kind of broker session cache).
If OJB lookup an object from the cache it doesn't expect an flat object.
Here we have to modify source in OJB or the cache implementation should
always return objects based on the metadata information (normally full
materialized objects).
Think in method #lookup(...) it will be possible to materialize the full
object using PB instance. OK, this will be tricky but I think not
impossible.
> A call to store() will not immediately put the objet in the second
> level cache but only in the first level (so this way other
> transactions are isolated from update on the objet since your
> transaction could finally abort)
> Rollbacking a transaction simply clear the first level cache (the
> broker session cache)
> Commiting the transaction transfert the object from the first level
> cache to the second level cache so that object update become visible
> to other transactions.
You do this in method PBStateListener#beforeCommit I would recommend to
use method #afterCommit, because when the commit fails (e.g. timed out
connection, ...) all changed objects will be in second level cache and
no rollback will be possible. On the other hand method #afterCommit will
not be called when connection commit fails.
In OJB1.0.1 I introduced a bug in method ObjectCacheDefaultImpl#buildKey
which you adopt in your implementation. Please get latest version from
OJB_1_0_RELEASE branch and replace that method (and add additional inner
class).
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/
cache/ObjectCacheDefaultImpl.java?rev=1.24.2.2&only_with_tag=OJB_1_0_REL
EASE&view=markup
If you agree I will replace the old TwoLevelCache implementation with
yours.
regards,
Armin
>
> There is 3 java files :
>
> AbstractTwoLevelObjectCache.java
> LocalTwoLevelObjectCache.java
> CopyHelper.java (you should use the last update for commons-bean for
this
> one)
> IFlatClone.java
>
> Just declare in OJB the LocalTwoLevelObjectCache for your new cache
handler.
>
> Here the code (sorry but it's not possible to attach file in the ojb
> user group) :
>
> package com.mycompagny.fwk.cache;
>
> import java.util.Hashtable;
> import java.util.Iterator;
> import java.util.Map;
> import java.util.Properties;
> import java.util.Map.Entry;
> import org.apache.commons.lang.builder.ToStringBuilder;
> import org.apache.commons.lang.builder.ToStringStyle;
> import org.apache.commons.lang.builder.HashCodeBuilder;
> import org.apache.ojb.broker.Identity;
> import org.apache.ojb.broker.PBStateEvent;
> import org.apache.ojb.broker.PBStateListener;
> import org.apache.ojb.broker.PersistenceBroker;
> import org.apache.ojb.broker.OJBRuntimeException;
> import org.apache.ojb.broker.cache.ObjectCache;
> import org.apache.ojb.broker.util.logging.Logger;
> import org.apache.ojb.broker.util.logging.LoggerFactory;
>
> /**
> *
> *
> * This abstract class implements the behavior of the session cache
> (first level cache)
> * and declare the abstract methods for implementing the application
> cache (second level cache).
> *
> *
> *
> */
> public abstract class AbstractTwoLevelObjectCache implements
> ObjectCache, PBStateListener
> {
>protected static final Logger LOG =
> LoggerFactory.getLogger(AbstractTwoLevelObjectCache.class);
>
>public static final String CACHING_KEY_TYPE_PROP =
"cachingKeyType";
>
>protected PersistenceBroker _broker;
>private Map _sessionCache;
>
>/**
> * Dete
Re: Another implementation of the Two Level Cache
Hi Jean-Baptiste,
CLARAMONTE Jean-Baptiste wrote:
Hello,
As I was not satisfy with the implementation of the TwoLevelCache,
mainly because it was not isolating the object in use in a transaction
with others transactions, so I've tried to write another one and now I
would like too share it with the community.
thanks for contribution!
You are right, the TwoLevelCache in CVS is only a alpha-version for a
two-level caching (upcoming OJB 1.1 in CVS trunk will support a real
two-level cache) and I never test it.
For resuming here are the behavior of this cache :
When you retrieve an object a flat copy are made
Your copy based on bean properties - or I'm wrong? I recommend to use
the OJB metadata information (associated FieldDescriptor of the object)
to make the copy. Because user could use different PersistentField
implementations (e.g. standard beans, only fields no getter/setter, dyna
beans,..).
In OJB trunk I introduce a class called SnapshotBuilder (alpha version)
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/cache/SnapshotBuilder.java?view=markup
To get a new object instance, please use ClassHelper#buildNewObjectInstance
This method include user defined object factories.
and the added in the
first level cache (a kind of broker session cache).
If OJB lookup an object from the cache it doesn't expect an flat object.
Here we have to modify source in OJB or the cache implementation should
always return objects based on the metadata information (normally full
materialized objects).
Think in method #lookup(...) it will be possible to materialize the full
object using PB instance. OK, this will be tricky but I think not
impossible.
A call to store() will not immediately put the objet in the second
level cache but only in the first level (so this way other
transactions are isolated from update on the objet since your
transaction could finally abort)
Rollbacking a transaction simply clear the first level cache (the
broker session cache)
Commiting the transaction transfert the object from the first level
cache to the second level cache so that object update become visible
to other transactions.
You do this in method PBStateListener#beforeCommit I would recommend to
use method #afterCommit, because when the commit fails (e.g. timed out
connection, ...) all changed objects will be in second level cache and
no rollback will be possible. On the other hand method #afterCommit will
not be called when connection commit fails.
In OJB1.0.1 I introduced a bug in method ObjectCacheDefaultImpl#buildKey
which you adopt in your implementation. Please get latest version from
OJB_1_0_RELEASE branch and replace that method (and add additional inner
class).
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/cache/ObjectCacheDefaultImpl.java?rev=1.24.2.2&only_with_tag=OJB_1_0_RELEASE&view=markup
If you agree I will replace the old TwoLevelCache implementation with yours.
regards,
Armin
There is 3 java files :
AbstractTwoLevelObjectCache.java
LocalTwoLevelObjectCache.java
CopyHelper.java (you should use the last update for commons-bean for this
one)
IFlatClone.java
Just declare in OJB the LocalTwoLevelObjectCache for your new cache handler.
Here the code (sorry but it's not possible to attach file in the ojb
user group) :
package com.mycompagny.fwk.cache;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
import java.util.Properties;
import java.util.Map.Entry;
import org.apache.commons.lang.builder.ToStringBuilder;
import org.apache.commons.lang.builder.ToStringStyle;
import org.apache.commons.lang.builder.HashCodeBuilder;
import org.apache.ojb.broker.Identity;
import org.apache.ojb.broker.PBStateEvent;
import org.apache.ojb.broker.PBStateListener;
import org.apache.ojb.broker.PersistenceBroker;
import org.apache.ojb.broker.OJBRuntimeException;
import org.apache.ojb.broker.cache.ObjectCache;
import org.apache.ojb.broker.util.logging.Logger;
import org.apache.ojb.broker.util.logging.LoggerFactory;
/**
*
*
* This abstract class implements the behavior of the session cache
(first level cache)
* and declare the abstract methods for implementing the application
cache (second level cache).
*
*
*
*/
public abstract class AbstractTwoLevelObjectCache implements
ObjectCache, PBStateListener
{
protected static final Logger LOG =
LoggerFactory.getLogger(AbstractTwoLevelObjectCache.class);
public static final String CACHING_KEY_TYPE_PROP = "cachingKeyType";
protected PersistenceBroker _broker;
private Map _sessionCache;
/**
* Determines how the key was build for the cached objects:
*
* 0 - Identity object was used as key
* 1 - Idenity + jcdAlias name was used as key
* 2 - Identity + model (DescriptorRepository) was used as key
* 3 - all together (1+2)
*/
private int cachingKeyType;
public AbstractTwoLevelObjectCache(PersistenceBroker broker,
Properties prop)
Re: Deadlocks mapped to common exception?
Oliver Zeigermann wrote: So, to get this going do you want me to prepare a patch for OJB which does exactly this: Introduce the createException method in the plattform class plus the exceptions and the initial code to feed it reasonably for Postgres, MySQL, SQLServer, and Sybase (is Sybase supported by OJB in the first place?)? +1 this will great! Will try, it might take some time... No problem. Maybe as a seconed step there could be a configuration mapping file ala Spring or Hibernate? +1 This could be an option for OJB 1.1 Considering what you said, you could just throw the exceptions and the user decides if he/she wants to redo the transaction or if it is a real programming error. This way there would be no need for a configurable mapping... ahh, misunderstand this. I thought user can configure which kind of exception will be thrown for an SQL error state, e.g. 345==>KeyKonstraintException. regards, Armin Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another implementation of the Two Level Cache
This pretty much is the mechanism the Slide project uses. AFAIK the isolation level is similar to READ_COMMITTED, isn't it? Oliver On Fri, 10 Dec 2004 13:18:53 +0100, CLARAMONTE Jean-Baptiste <[EMAIL PROTECTED]> wrote: > Hello, > > As I was not satisfy with the implementation of the TwoLevelCache, > mainly because it was not isolating the object in use in a transaction > with others transactions, so I've tried to write another one and now I > would like too share it with the community. > For resuming here are the behavior of this cache : > When you retrieve an object a flat copy are made and the added in the > first level cache (a kind of broker session cache). > A call to store() will not immediately put the objet in the second > level cache but only in the first level (so this way other > transactions are isolated from update on the objet since your > transaction could finally abort) > Rollbacking a transaction simply clear the first level cache (the > broker session cache) > Commiting the transaction transfert the object from the first level > cache to the second level cache so that object update become visible > to other transactions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deadlocks mapped to common exception?
On Fri, 10 Dec 2004 13:16:24 +0100, Armin Waibel <[EMAIL PROTECTED]> wrote: > What is the "top level"? Slide itself or the app using Slide. If you run > a persistence layer in a managed environment (like a j2ee conform > appServer) it is not possible for the persistence layer to restart the > tx, because tx demarcation is handled by the container or bean or by the > client using UserTransaction(and tx could be a distributed tx). > So +1 for improving exception handling like you suggest, but -1 for all > stuff like automatic tx redo on persistence layer level. Or I'm wrong > and Slide could handle this in managed environments? Agreed. Slide uses a UserTransaction, rolls it back and restarts it. This is not on the persistence layer. Thus OJB should not restart anything as well, but just throw the exception and the user needs to decide what is to be done. > > > Slide also has some internal locking which can be used > > to either completely eliminate deadlocks (at the cost of no > > concurrency while writing) or at least limit its likelyhood. > > > > PB-api only supports optimistic locking. The odmg-api supports > pessimistic + optimistic locking (with configurable lock modes). > Pessimistic locking should be able to prevent DB deadlock (dependent on > odmg lock mode and DB lock mode). I can imagine scenarios when pessimistic (blocking) locks in the persistence layer can cause distributed (unresolvable) deadlocks. This can be when the DB has more coase grain locks than the persistence code or when there are transactions that do not use the persistence layer at all. > > I have been > > told that Hibernate (2.1.7) supports a mapping with an (XML?) > > configuration file: > > > > http://forum.hibernate.org/viewtopic.php?p=2223974 > > > > Maybe as a default all of the Exceptions mentioned above should cause > > the transaction to be redone? > > see beginning of response, maybe I misunderstand you ;-) Agreed. > > So, to get this going do you want me to prepare a patch > > for OJB which does exactly this: Introduce the createException method > > in the plattform class plus the exceptions and the initial code to > > feed it reasonably for Postgres, MySQL, SQLServer, and Sybase (is > > Sybase supported by OJB in the first place?)? > > +1 this will great! Will try, it might take some time... > > Maybe as a seconed step > > there could be a configuration mapping file ala Spring or Hibernate? > > > > +1 This could be an option for OJB 1.1 Considering what you said, you could just throw the exceptions and the user decides if he/she wants to redo the transaction or if it is a real programming error. This way there would be no need for a configurable mapping... Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: starting ojb
Dnia piątek, 10 grudnia 2004 10:26, [EMAIL PROTECTED] napisał: Hi, Did you put repository.dtd file into this folder? Regards. > I have always the same problem. I have put the needed xml files in the > folder where my application is. but there is the same mistake. > > [JDO] DEBUG: OjbStoreConnector.begin: connectionReadyForRelease=false > org.apache.ojb.broker.PBFactoryException: There was no default-PBKey > specified > at > org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersiste >nceBroker(Unknown Source) > at > org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker(Unk >nown Source) > at org.apache.ojb.jdori.sql.OjbStoreConnector.begin(Unknown > Source) > at com.sun.jdori.common.TransactionImpl.beginInternal(Unknown > Source) > at com.sun.jdori.common.TransactionImpl.begin(Unknown Source) > at org.myProject.appli.Demo.storing(Demo.java:97) > at org.myProject.appli.Demo.main(Demo.java:110) > Exception in thread "main" > > which information do you need to get an idea where the mistake is.? > > > regards > > > Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Another implementation of the Two Level Cache
Hello,
As I was not satisfy with the implementation of the TwoLevelCache,
mainly because it was not isolating the object in use in a transaction
with others transactions, so I've tried to write another one and now I
would like too share it with the community.
For resuming here are the behavior of this cache :
When you retrieve an object a flat copy are made and the added in the
first level cache (a kind of broker session cache).
A call to store() will not immediately put the objet in the second
level cache but only in the first level (so this way other
transactions are isolated from update on the objet since your
transaction could finally abort)
Rollbacking a transaction simply clear the first level cache (the
broker session cache)
Commiting the transaction transfert the object from the first level
cache to the second level cache so that object update become visible
to other transactions.
There is 3 java files :
AbstractTwoLevelObjectCache.java
LocalTwoLevelObjectCache.java
CopyHelper.java (you should use the last update for commons-bean for this
one)
IFlatClone.java
Just declare in OJB the LocalTwoLevelObjectCache for your new cache handler.
Here the code (sorry but it's not possible to attach file in the ojb
user group) :
package com.mycompagny.fwk.cache;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
import java.util.Properties;
import java.util.Map.Entry;
import org.apache.commons.lang.builder.ToStringBuilder;
import org.apache.commons.lang.builder.ToStringStyle;
import org.apache.commons.lang.builder.HashCodeBuilder;
import org.apache.ojb.broker.Identity;
import org.apache.ojb.broker.PBStateEvent;
import org.apache.ojb.broker.PBStateListener;
import org.apache.ojb.broker.PersistenceBroker;
import org.apache.ojb.broker.OJBRuntimeException;
import org.apache.ojb.broker.cache.ObjectCache;
import org.apache.ojb.broker.util.logging.Logger;
import org.apache.ojb.broker.util.logging.LoggerFactory;
/**
*
*
* This abstract class implements the behavior of the session cache
(first level cache)
* and declare the abstract methods for implementing the application
cache (second level cache).
*
*
*
*/
public abstract class AbstractTwoLevelObjectCache implements
ObjectCache, PBStateListener
{
protected static final Logger LOG =
LoggerFactory.getLogger(AbstractTwoLevelObjectCache.class);
public static final String CACHING_KEY_TYPE_PROP = "cachingKeyType";
protected PersistenceBroker _broker;
private Map _sessionCache;
/**
* Determines how the key was build for the cached objects:
*
* 0 - Identity object was used as key
* 1 - Idenity + jcdAlias name was used as key
* 2 - Identity + model (DescriptorRepository) was used as key
* 3 - all together (1+2)
*/
private int cachingKeyType;
public AbstractTwoLevelObjectCache(PersistenceBroker broker,
Properties prop)
{
this._broker = broker;
cachingKeyType = prop == null ? 0 :
(Integer.parseInt(prop.getProperty(CACHING_KEY_TYPE_PROP, "0")));
if (broker != null)
{
// we add this instance as a permanent PBStateListener
broker.addListener(this, true);
}
_sessionCache = new Hashtable();
}
/**
* Clear the session cache(first level cache) and the application
cache (second level cache)
*/
public void clear()
{
clearApplicationCache();
_sessionCache.clear();
}
/**
* Makes object persistent to the sessionCache.
* even if they are still cached.
*/
public void cache(Identity oid, Object obj)
{
if ((obj != null))
{
addToSessionCache(oid, obj);
}
}
/**
* Lookup object with Identity oid in :
* sessionCache, if not found in sessionCache the lookup the
applicationCache.
* Returns null if no matching id is found
*/
public Object lookup(Identity oid)
{
LOG.debug("lookup()");
Object result = null;
CacheEntry entry = null;
// first lookup if the object is available in the application cache
result = lookupSessionCache(oid);
if (result!=null)
return result;
// If not then lookup in the application cache :
entry = lookUpApplicationCache(oid);
if (entry != null &&
entry.getOid().getObjectsTopLevelClass().equals(oid.getObjectsTopLevelClass(
)))
{
LOG.debug("Object found in Application Cache");
Object objectFromApplicationCache = entry.getObject();
if (objectFromApplicationCache == null)
{
remove(oid);
// make sure that we return null
result = null;
}
else
{
// Make a copy WITHOUT any reference to other object
// (just copy the java type : have a look at
CopyHelper.copyJavaTypeProperties()
// for more information)
Re: Deadlocks mapped to common exception?
Oliver Zeigermann wrote: can anyone tell me if OJB is able to find out that a certain SQL exception really is a deadlock exception and maps it to another common one (DeadlockException)? This would be very helpful to repeat a deadlocked transaction. I found no code in OJB that might do such a job. You are right. OJB wraps all SQLException as PersistenceBrokerSQLException (except key constraint errors here OJB use a specific exception). See JdbcAccessImpl#executeInsert. PBSE is an unchecked exception and with #getCause() you can extract the SQLException. If there is nothing in OBJ the Jakarta Slide project has some initial code that does this for some dbs. Maybe this could be integrated in OJB? hmm, I only found some code in PostgresRDBMSAdapter#createException. Were can I find the common code for deadlock handling? Until now code to detect an exception really is a deadlock exception is available for Postgres, MySQL, SQLServer and Sybase only. Slide also supports DB2 and Oracle, but the code for them still is missing. The rest of the code merely catches the DeadLockException at top level, rolls back the transaction, starts a new one and repeats the whole request. What is the "top level"? Slide itself or the app using Slide. If you run a persistence layer in a managed environment (like a j2ee conform appServer) it is not possible for the persistence layer to restart the tx, because tx demarcation is handled by the container or bean or by the client using UserTransaction(and tx could be a distributed tx). So +1 for improving exception handling like you suggest, but -1 for all stuff like automatic tx redo on persistence layer level. Or I'm wrong and Slide could handle this in managed environments? Slide also has some internal locking which can be used to either completely eliminate deadlocks (at the cost of no concurrency while writing) or at least limit its likelyhood. PB-api only supports optimistic locking. The odmg-api supports pessimistic + optimistic locking (with configurable lock modes). Pessimistic locking should be able to prevent DB deadlock (dependent on odmg lock mode and DB lock mode). However, it turned out that when using low isolation levels there may be constraint violations which would not occur if you had your transactions serializable. They would have to be treated just like a deadlock or "can not serialize error". As this really depends on your database schema and constraints I guess it is impossible to do this in a completely generic way. agree, in the Platform classes #createException(...) method we can only use method arguments like - the SQLExeption - the connection itself or the connection transaction isolation - the causing object - metadata of causing object I have been told that Hibernate (2.1.7) supports a mapping with an (XML?) configuration file: http://forum.hibernate.org/viewtopic.php?p=2223974 Maybe as a default all of the Exceptions mentioned above should cause the transaction to be redone? see beginning of response, maybe I misunderstand you ;-) On the other hand contraint violations really can indicate programming errors... I know it is always tricky to ask for new features without contributing. No problem, you can ask, but you shouldn't be expect a implementation guarantee for the new features ;-) So, to get this going do you want me to prepare a patch for OJB which does exactly this: Introduce the createException method in the plattform class plus the exceptions and the initial code to feed it reasonably for Postgres, MySQL, SQLServer, and Sybase (is Sybase supported by OJB in the first place?)? +1 this will great! Maybe as a seconed step there could be a configuration mapping file ala Spring or Hibernate? +1 This could be an option for OJB 1.1 regards, Armin Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Concurrency: Best practices
Hi,
we are currently working at an web-application, which is currently
single-threaded. For performance reason it is obvious that it should be
multi-threaded. We are using OJB as persistence-layer. Now my question:
Does anyone has best practices for creating an thread-safe object-model?
Suppose we have the following class:
class Person {
String getName();
void setName(String aName);
void addTeam(Team t);
Collection getTeams();
void removeTeam(Team t);
}
What would be the best version of this class? What methods should be
synchronized and which methods don't have to be synchronized?
If someone has a hint where I could learn that, I'd really appreciate that.
With regards
Tino
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: starting ojb
Hi Michael, You said earlier "I have put the needed xml files in the folder where my application is" - could you please be a little clearer ? Could you show us the folder layout - i.e. where the classes are, where the xml files are, what the names of the xml files are, and what the working/current directory is when the application is run ? By default, OJB will look for a file called "repository.xml" - it will first look for a resource on the classpath - and if that fails, it will look in the file file system. Also, I would suggest turning on some logging (see http://db.apache.org/ojb/docu/guides/logging.html) for more info. The RepositoryPersistor class actually logs which file it is loading. I hope that helps a little Cheers, Charles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 10 December 2004 09:57 To: OJB Users List Subject: RE: starting ojb Yes i did it. This is the part of my repository_database.xml ___ HPD Software Ltd. - Helping Business Finance Business Email terms and conditions: www.hpdsoftware.com/disclaimer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: starting ojb
Yes i did it. This is the part of my repository_database.xml
RE: starting ojb
Did you set the following in one jdbc-connection-descriptor: default-connection="true" example: Roland Ribi > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Friday, December 10, 2004 10:26 AM > To: [EMAIL PROTECTED] > Subject: starting ojb > > > I have always the same problem. I have put the needed xml > files in the > folder where my application is. but there is the same mistake. > > [JDO] DEBUG: OjbStoreConnector.begin: connectionReadyForRelease=false > org.apache.ojb.broker.PBFactoryException: There was no default-PBKey > specified > at > org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.de > faultPersistenceBroker(Unknown > Source) > at > org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersiste > nceBroker(Unknown > Source) > at org.apache.ojb.jdori.sql.OjbStoreConnector.begin(Unknown > Source) > at com.sun.jdori.common.TransactionImpl.beginInternal(Unknown > Source) > at com.sun.jdori.common.TransactionImpl.begin(Unknown Source) > at org.myProject.appli.Demo.storing(Demo.java:97) > at org.myProject.appli.Demo.main(Demo.java:110) > Exception in thread "main" > > which information do you need to get an idea where the mistake is.? > > > regards > > > Michael > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
starting ojb
I have always the same problem. I have put the needed xml files in the folder where my application is. but there is the same mistake. [JDO] DEBUG: OjbStoreConnector.begin: connectionReadyForRelease=false org.apache.ojb.broker.PBFactoryException: There was no default-PBKey specified at org.apache.ojb.broker.core.PersistenceBrokerFactoryBaseImpl.defaultPersistenceBroker(Unknown Source) at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker(Unknown Source) at org.apache.ojb.jdori.sql.OjbStoreConnector.begin(Unknown Source) at com.sun.jdori.common.TransactionImpl.beginInternal(Unknown Source) at com.sun.jdori.common.TransactionImpl.begin(Unknown Source) at org.myProject.appli.Demo.storing(Demo.java:97) at org.myProject.appli.Demo.main(Demo.java:110) Exception in thread "main" which information do you need to get an idea where the mistake is.? regards Michael
