>> multiple connections
>> from a connection pool.
>
> I understand. It's probably not a good idea to open a new connection
> for each operation, because for some databases opening a connection
> takes very long. I have implemented a simple pool (with maxSize) now,
> I like to test it a little before committing it.
Indeed, the code I posted did exactly that, but the idea was that it was very
easy to subclass it
and change the way a connection is obtained.
> It probably makes sense to make the class extensible, but I don't know
> yet where exactly this should be. I will make all methods and
> variables protected.
That's a start. Ideally, I think we should do something like the template
method pattern.
I have a few other suggestions for code changes:
* add a getter for the identifier in BLOBInDataStore (to be used by the GC)
* make RepositoryImpl.getWorkspaceNames() public
>> I tested with SQL Server 2005 with the default statements, and they don't
>> work because the BLOB
>> data
>> type is called IMAGE there. I changed it and everything else works fine.
>
> OK. So the bugfix is to replace sqlserver.properties with:
> driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
> createTable=CREATE TABLE DATASTORE(ID VARCHAR(255) PRIMARY KEY, LENGTH
> BIGINT, LAST_MODIFIED BIGINT, DATA IMAGE)
>
> Is this OK?
At the very least, I would put all the statements in the properties file,
because there's no
documentation about them.
>> No, it's not required, but if all you want to do is change the table name, I
>> think it's too much
>> having to re-write all the statements.
>
> I don't understand, why do you want to change the table name specially
> for one database type? Or do you mean make the table name
> configurable? That does make sense (if you want to store it in another
> schema for example). Should I implement the ${schemaObjectPrefix} as
> you have done?
Yes, I meant that the table name shoud be configurable. I used the
${schemaObjectPrefix} idea
because it's the way it's done in other parts of the core.
>> Just doing the following in a class that extends AbstractJCRTest is enough
>>
>> Session session = helper.getSuperuserSession();
>> Node root = session.getRootNode();
>> root.setProperty("notice", new FileInputStream("NOTICE.txt"));
>> session.save();
>
> OK thank for the test case! I didn't have time yet to find out how to
> solve this performance problem.
On a related note, the fact that when you ask for a stream it is first written
to disk, is by
design?
Because if it's not, then I think another problem will arise later. Since the
streams are written to
disk, and from there sent to the clients, you can have multiple streams open at
the same time
(that's the idea). But if you fix this and start feeding the streams straight
from the DB, then,
since you only have one connection, you can have only one outstanding stream.
Maybe I'm wrong here,
but in my initial testing I couldn't feed two or more streams through the same
connection.
Regards,
Esteban Franqueiro
[EMAIL PROTECTED]
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.
