2007/3/4, Joerg Heinicke <[EMAIL PROTECTED]>:
Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:
> As explaining in my previous post, I have created a new TRANSACTION2
> branch to contain initial code, docs, etc. for a future 2.0 version of
> Commons Transaction.
>
> If you have ideas, suggestions, etc. please follow up to this post
> until we find a more suitable place for such a discussion.
>
> Open Questions (my suggestions in brackets):
> 1.) Medium for discussion (Wiki? SVN?)
Why not this list? Do you expect so much discussion?
OK
> 3.) Minimum JDK Requirement (always the latest, i.e. 1.6)
Hmm, why require more than necessary? Java 5 brings the concurrent package, but
Java 6? Higher requirements always limit the number of users.
OK
> 4.) Scope (all restricted as possible)
Scope of what? Access scope of interfaces, classes, methods? Normally I tend to
limit it as less as possible to allow easy extending and sub classing. But if
changes to the API are always related with such "circumstances" ...
Scope of the implementation. Means only implement core, leave the rest
to optional modules and custom implementation.
My idea (and what I have learned from 1.x) is to only impement a core
that does the transactional part. The rest can in done through calling
implementation of interfaces
- How does a transaction map to temporary data
- Where is temporary data and final data stored (maybe use VFS?)
- Id generator
- what else?
There should be a default implementation for interfaces, but it should
be slim and rudimentary. This may result in having a transactional
file store out of the box.
Open Questions:
- Is Jakarta Commons the right place for such a project?
- Should we introduce threading in order to
- Allow remote access / administration to a file store
- Allow for deadlock detection in its own thread
- what else?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
