Possible bug in JDBCDescriptorStore or MySQL driver?

[Tom Keeney <to...@novuscg.com>]

Hello All,

I have a rather peculiar situation with my Slide distribution.  First, here's my configuration:

Jakarta Slide 1.0.16
MySQL 3.23.49 with transaction support
mm.mysql-2.0.12 driver

Slide database is running on Solaris 8.
Slide application code is running on Windows 2000.

I developed a Slide client application that administers users in the Slide database.  The client adds slide users and modifies their passwords using the Slide Helpers.  In order for Slide to pick up any changes to the user properties, I turned off caching in the source code (i.e. made AbstractServiceBase.cacheResults() return false).  Everything works fine if I have the slide database set up on MyISAM tables.  In other words, my client application adds a user or changes their password property, and the SlideRealm picks up this change.  However, when I port the slide database to InnoDB tables, the SlideRealm doesn't pick up modifications to the user properties.  I traced the problem to the ResultSet returned in JDBCDescriptorsStore.retrieveRevisionDescriptor(Uri uri, NodeRevisionNumber revisionNumber):

            statement = connection.prepareStatement
                ("select * from property where uri= ? and xnumber = ?");
            statement.setString(1, uri.toString());
            statement.setString(2, revisionNumber.toString());
            res = statement.executeQuery();

This statement reports that the user password (for example) hasn't changed even though I changed it with my client code and the mysql client shows that the password has in fact been modified in the database.

I'm guessing that the PreparedStatement may be caching the results?  Or perhaps there's a problem with the MM driver.  I upgraded to the mmy.mysql-2.0.14 driver but the problem still persists.  Does anyone have any ideas on this problem?

Thanks in advance,

Tom Keeney
Novus Consulting Group
 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Possible bug in JDBCDescriptorStore or MySQL driver?

[Kevin Moran <gr...@yahoo.com>]

Hi Tom,
    I don't know if this suggestion is of any
practical use to you, but have you confirmed that your
code is calling NamespaceAccessToken.begin() just
before it tries to update Slide and
NamespaceAccessToken.commit() immediately afterwards? 
You responded a while back to a problem I was having
with caching in JDBCDescriptorsStore; specifically
that it wasn't flushing out data to my Oracle
database.  What fixed my problem -- and I'm just
wondering if it's related to what you're describing --
is that I started calling begin() and commit().  I
didn't need to turn off caching in
AbstractServiceBase, just wrap my transaction in calls
to begin() and commit().  If I didn't call those
methods, I would see the code work for some DBs (e.g.,
HSql) and not others (Oracle).  I'm just wondering if
you're experiencing a similar caching problem.

Best,
-kevin


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>