db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Schlabach <TSchlab...@gmx.net>
Subject RE: Oracle 9i BLOB malfunction / 4k mystery (issue OJB170)
Date Fri, 16 May 2003 07:11:42 GMT
Lance,

> Alternatively I personally could live with having to make two calls to 
> workaround this problem:
> 
>    broker.store(myObject);
>    OracleBLOBPatch.storeBlobs(broker, myObject, ...whatever else it 
> needs...);
> 
> As you say though this starts to break encapsulation and not knowing 
> anything about the ODMG side of OJB I don't know if it causes havoc 
> there.

To me this has both a tactical and a strategic perspective.

On that tactical layer I will implement the OracleLOBPatch today in order
for my vertical project using OJB to be able to move on.

But I still consider this a hack we do not really want to have as it breaks
*any* database independency of application code using OJB. I don't think we
want to go further down that road, especially as we do not yet know that this
will lead to regarding ODMG et. al.

So I will take the time to follow up the rumors on the list that different
people were working on a solution or have posted code already. When it comes
to Thomas Poeschmann at least I understand that his "solution" that people
were waiting on turned out as using the OCI driver.

Per-Olof posted a fix that made it to the CVS last week, but that one does
not address the 4K issue at all. As least not in my test.

Thomas Mahler stated that

a) Oracle claimed to have fixed "the issue".
b) Michael Mogley is refactoring his initial fix to reduce the impacts on
the wider OJB codebase.

on a: I asked him to provide a link as this information conflicts which what
I found from Oracle. AFAIK this is not really an *issue* but much more a
decision made by Oracle not to implement a specific part of the JDBC standard
(PreparedStatement.getBinarySteam / PreparedStatement.setBinaryStream) in their
thin driver for whatever reason they might have.

on b: Need to check. I am not aware of his "initial fix". Maybe someone can
save me some time by posting a reference as well.

By the way and just to round that up: Did anyone ever think of Oracle 9
BFILEs in this respect?

Torsten


> As I understand the state of the world it's hard to fit a fix for this 
> into OJB's current model because at the FieldConversion level there's no 
> access to the primary key info.  But Oracle's workaround involves doing 
> a select for update on the row therefore you need primary key info.  
> Getting primary key info down to the FieldConversion level involves some 
> distasteful mucking with some number of interfaces all to work around a 
> bug that's Oracle's fault in the first place.
> 
> Backing up a few levels though, all updates ultimately originate from 
> PersistenceBroker.store().  PersistenceBroker implementations are 
> replaceable through OJB properties.  What I'm imagining is a 
> PersistenceBrokerToPatchOraclesBloodyStupidBlobProblemImpl that 
> basically delegates to a normal PersistenceBroker to store all the 
> non-BLOB/CLOB columns and handles those itself specially.  I am 
> admittedly fuzzy on how it would accomplish delegating only a subset of 
> the columns (I'm imagining something involving custom attributes on 
> <field-descriptor> mappings or some such) and there may be other 
> interception points that make more sense, but somewhere there should be 
> some interception point between PersistenceBroker.store() and the 
> FieldConversion level that has enough context (i.e. access to primary 
> key info) to do the right thing.
> 
> Alternatively I personally could live with having to make two calls to 
> workaround this problem:
> 
>    broker.store(myObject);
>    OracleBLOBPatch.storeBlobs(broker, myObject, ...whatever else it 
> needs...);
> 
> As you say though this starts to break encapsulation and not knowing 
> anything about the ODMG side of OJB I don't know if it causes havoc 
> there.
> 
> -----Original Message-----
> From: Torsten Schlabach [mailto:tschlabach@gmx.net]
> Sent: Thursday, May 15, 2003 11:28 PM
> To: 'OJB Developers List'
> Subject: AW: Oracle 9i BLOB malfunction / 4k mystery (issue OJB170)
> 
> 
> >> OJB let's you access the JDBC layer so you can work around it
> yourself
> 
> Can you tell in short words how that would look like? I am not yet sure.
> Also, won't that totally break the idea of encapsulation or layering in
> the application. It might be a way of getting this to work *now*, but no
> really a solution.
> 
> -----Urspr├╝ngliche Nachricht-----
> Von: Lance Eason [mailto:lance.eason@whisperwire.com] 
> Gesendet: Donnerstag, 15. Mai 2003 23:18
> An: OJB Developers List; thma@apache.org
> Betreff: RE: Oracle 9i BLOB malfunction / 4k mystery (issue OJB170)
> 
> Yeah, you're right.  I realized after I wrote the note that OJB let's
> you access the JDBC layer so you can work around it yourself.  As one of
> the people burned by this problem I'd actually be perfectly happy if
> core OJB wasn't modified but the problem was clearly documented and
> sample workaround code was provided and ideally some patch utility class
> was provided to do the repetitive work of doing the SELECT FOR UPDATE
> and writing out the contents.
> 
> -----Original Message-----
> From: Thomas Mahler [mailto:thma32@web.de]
> Sent: Thursday, May 15, 2003 2:15 PM
> To: OJB Developers List
> Subject: Re: Oracle 9i BLOB malfunction / 4k mystery (issue OJB170)
> 
> 
> Hi angain
> 
> Lance Eason wrote:
> > I'll answer the first question.  It is most definitely an Oracle bug.
> > Regardless it is important that OJB address it in my opinion.  
> 
> +1
> 
> > Users
> > using JDBC directly can work around this bug, users using OJB
> > currently cannot.  
> 
> As it's pretty OK to use OJB to obtain JDBC connections you can use OJB 
> *and* use direct JDBC calls to work around this problem.
> 
> > That creates a decision point when BLOB/CLOB data
> > is required of use Oracle or use OJB and to most people the DBMS is
> > going to be the higher priority.
> 
> don't agree, see above.
> 
> > 
> > And yes the OCI driver does not exhibit this bug but it is not always
> > possible to use the OCI driver.  First it requires an Oracle client
> > installation on each machine and second it is native code and at
> > least for Oracle 8.1.7 is flaky (many, many SEGFAULTs in our recent
> > load testing).
> 
> As I mentioned in my other mail, Oracle seems to have fixed the 
> CLOB/BLOB problems with the thin driver in their latest release!
> 
> I think we should further investigate this before launching bug fix 
> rampage. ;-)
> 
> cheers,
> thomas
> 
> > 
> > -----Original Message----- From: Torsten Schlabach
> > [mailto:TSchlabach@gmx.net] Sent: Thursday, May 15, 2003 6:29 AM To:
> > ojb-dev@db.apache.org Subject: Re: Oracle 9i BLOB malfunction / 4k
> > mystery (issue OJB170)
> > 
> > 
> > Folks,
> > 
> > if I get this right, we still don't have a *real* solution to this,
> > do we? I found that Per-Olof's CLOB patch for using the thin driver
> > made it to the CVS, but I understand it only fixes this for text < 4
> > KB, right?
> > 
> > So first of all I thought it was a good idea to enter an issue in the
> > bug database at http://scarab.werken.com/scarab/issues/id/OJB170
> > (which became OJB170).
> > 
> > So to me there are at two questions right now:
> > 
> > 1. Is this an OJB bug, an Oracle bug or both? 2. How do we *want* do
> > handle this at all?
> > 
> > What I mean is: To what column type would I map a String object that
> > I except to grow very large (i.e. some dozends KB of text)?
> > 
> > I might map it to JDBC type CLOB which would be closest to reality
> > but this will break with a class cast exception (you cannot cast a
> > string to a java.sql.Clob).
> > 
> > If you map it to anything else such as LONGVARCHAR Oracle will not
> > care but this will probably break other things.
> > 
> > In fact it might depend on your application what you want back in
> > your bean when using a CLOB column: You either might want to get a
> > stream you can read from in some other place or you might want to
> > just get the stuff into a String and not care about it any more
> > (which would make your application code much less Oracle specific by
> > the way).
> > 
> > This is essentially two different JDBC types needed for the same type
> > of DB column. Does the framework support this at all? I am wrong in
> > any assumption?
> > 
> > Torsten
> > 
> > P.S.: I would like to post this as a comment in Scarab, but I did not
> > yet find out how to edit the issue. I was able to submit it though.
> > Any help appreciated.
> > 
> > Original Message: ----------------- From: Thomas Poeschmann
> > t.poeschmann@exxcellent.de Date: Mon, 12 May 2003 16:05:08 +0200 To:
> > ojb-dev@db.apache.org Subject: Re: Oracle 9i BLOB malfunction / 4k
> > mystery
> > 
> > 
> > Hi there,
> > 
> > 
> >> Michael Mogley wrote: Thomas Poeschmann says on the list that he
> >> almost has a solution, using the above method I presume.
> > 
> > 
> > Yes, of course using the SELECT FOR UPDATE. Sorry for promising
> > posting code but not doing it, but I will try to find it this
> > evening. It is probably just for reference for you, since you already
> > have it.
> > 
> > 
> >> Are there other dbmses and drivers that exhibit the same irregular
> >>  behavior regarding LOB┬┤s.
> > 
> > 
> > Not that I know. Sometimes it is different to call one of the methods
> > on a statement to bring certain Java objects in. For example passing
> > an array in as a String. But I have never seen anything hard as
> > Oracle XLOBs ;)
> > 
> > 
> >> Unfortunatly, our solution (apart from the the fix submitted)
> >> currently consists of changing to the oci driver. Sad but true.
> > 
> > 
> > Which has other drawbacks, but well... Other ORM can not handle it
> > either with thin, by the way ;)
> > 
> > Kind regards,
> > 
> > Thomas
> > 
> > 
> > ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For
> > additional commands, e-mail: ojb-dev-help@db.apache.org
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For
> > additional commands, e-mail: ojb-dev-help@db.apache.org
> > 
> > 
> > ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For
> > additional commands, e-mail: ojb-dev-help@db.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 


Mime
View raw message