openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: OPENJPA-182: reuse Connection constants or create our own?
Date Tue, 17 Apr 2007 19:10:02 GMT
I suggest that you either add a patch to the issue, or open a new
sub-issue that outlines this particular problem.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
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. 

> -----Original Message-----
> From: Ritika Maheshwari [mailto:ritikamster@gmail.com] 
> Sent: Tuesday, April 17, 2007 12:04 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: OPENJPA-182: reuse Connection constants or 
> create our own?
> 
> Patrick,
>             we just discovered that there is a problem with 
> this fix.Theproblem is that the FOR READ ONLY flag is getting 
> generated for subselects as well.
> 
> Basically for DB2 if forUpdate was false we append FOR READ 
> ONLY we need another check to see that it is not a 
> subselect.To me it appears that in the toSelect method when 
> SelectImpl is passed we check that the parent is null or not 
> to figure out that it is a subselect and then pass another 
> flag subselect to the getForUdateClause method where we say
>     if(!forUpdate && !subselect)
>          forUpdateString.append(forReadOnlyClause)
> to achieve this we would probably have to override the 
> toSelect methods in DB2Dictionary again unless there is a better way.
> 
> 
> On 4/10/07, Patrick Linskey <plinskey@bea.com> wrote:
> >
> > As long as any given enum instance that corresponds to a 
> > theoretically-unique enum value has internally-consistent state, we 
> > should be in good shape. IOW, if the enum constructors are called 
> > appropriately or internal state is otherwise maintained, 
> then things 
> > should work out fine.
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > BEA Systems, Inc.
> >
> > 
> ______________________________________________________________________
> > _
> > 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.
> >
> > > -----Original Message-----
> > > From: Marina.Vatkina@Sun.COM [mailto:Marina.Vatkina@Sun.COM]
> > > Sent: Tuesday, April 10, 2007 4:56 PM
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: Re: OPENJPA-182: reuse Connection constants or 
> create our 
> > > own?
> > >
> > > It should be ok anyway in the same VM. Unfortunately I had 
> > > conflicting messages on weather it's the name or the 
> ordinal that is 
> > > guaranteed to work across the VMs :(.
> > >
> > > -marina
> > >
> > > Patrick Linskey wrote:
> > > > Fascinating. Happily, as it turns out, we never compare these 
> > > > things directly; instead, we extract a value from the enums and
> > > use that. The
> > > > value is populated in the enum constructor:
> > > >
> > > > public enum IsolationLevel {
> > > >     DEFAULT(-1),
> > > >     NONE(Connection.TRANSACTION_NONE),
> > > >     READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
> > > >     READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
> > > >     REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
> > > >     SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
> > > >
> > > >     private final int _connectionConstant;
> > > >
> > > >     private IsolationLevel(int connectionConstant) {
> > > >         _connectionConstant = connectionConstant;
> > > >     }
> > > >
> > > >     protected int getConnectionConstant() {
> > > >         return _connectionConstant;
> > > >     }
> > > > }
> > > >
> > > > Do you know if the getConnectionConstant() method would
> > > return the same
> > > > value for different instances of the "same" module?
> > > >
> > > > -Patrick
> > > >
> > >
> > >
> >
> > 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.

Mime
View raw message