Well, we could also switch to the "sync before close" option. It
automatically bypasses all these tricky questions. Since we already
have all these files open for writing, anyway, it makes sense to do
the syncing with those descriptors?
It's just that commit() is somewhat awkward in that case as it must
force a partial merge so it can then sync that segment.
Mike
"robert engels" <[EMAIL PROTECTED]> wrote:
> I would argue that implementation does not adhere to the published
> API...
>
> On Nov 30, 2007, at 12:48 PM, Yonik Seeley wrote:
>
> > On Nov 30, 2007 1:18 PM, robert engels <[EMAIL PROTECTED]> wrote:
> >> I don't know, the Java guys are pretty good about making sure their
> >> API works consistently across all platforms, or at least documenting
> >> the cases where it wouldn't.
> >
> > One way to consistency is a lowest-common-denominator approach.
> > Here is harmony's implementation:
> >
> > + public void sync() throws SyncFailedException {
> > + // if the descriptor is a read-only one, do nothing
> > + if (!readOnly) {
> > + syncImpl();
> > + }
> > + }
> >
> >
> > https://issues.apache.org/jira/browse/HARMONY-1494
> > http://forum.java.sun.com/thread.jspa?
> > threadID=5158868&messageID=9605637
> >
> >> I would start with a read only descriptor and get it into the field.
> >
> > Given that there are a large number of platforms where it could be
> > expected to either fail or succeed and do nothing, it doesn't seem
> > like the right approach.
> >
> > -Yonik
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
