Forums Register Login

reading STATUS FLAG 0/1

+Pie Number of slices to send: Send
Hi,
The first field in the record is the status (active/deleted record). I am trying now to change my IO mechanism to use FileChannel.
Using old streams (DatainputStream) it was easy: I read 1 byte and if its 1 (deleted) I go to the next record.
Using FileChannel I can use ByteBuffer. I can decode then it in CharBuffer, but what about the first? I can not use readByte(), I must initialize ByteArray[].allocate(1),
then if the value is not 1, I must initialize ByteArray[].allocate(RECORD_LENGTH).
It looks not so good.
How should normally handle this task?
Thanx,
Vlad
+Pie Number of slices to send: Send
Hi Vlad
I had the same problem until I found this...
byte b = buffer.get();
//When b is cast up to int, the sign bit (0 or 1) is extended to fill
//the top three bytes of the resulting int, while the bottom byte remains
//the original binary value of b. When we mask that against 255
//(which is all ones in the bottom byte, the rest are zeros)
//we lose the upper sign bits (if any), and are left with only the binary
//value of b.
int flag = b & 255;
Just like RAF.readUnsignedByte(). It works, but I'm seriously considering switching back to standard RAF because of SUNs emphasis is on simplicity.
Cheers
Gareth.
+Pie Number of slices to send: Send
Hi Gareth,
Thanx you for the fast reply.
If understand you correctly we still have the problem:
Choise 1:
ByteBuffer bb = ByteBuffer.allocate(RECORD_LENGTH);
fileChannel_.read(bb);
bb.flip();
byte b = bb.get();
int flag = b & 255;
...
Choise 2:
ByteBuffer bb = ByteBuffer.allocate(1);
fileChannel_.read(bb);
bb.flip();
byte b = bb.get();
int flag = b & 255;
if (flag)== 0 then... read the rest.

In first case we have to read whole record every time (Using RAF we would not read the rest if flag ==1)
In second case we we two allocate one ByteBuffer just for flag, and one for the rest.
If these assumptions are correct, what performance ?
Regards,
Vlad
+Pie Number of slices to send: Send
Hi Vlad,
I meant to stay away for the weekend and write, but since I've got you on this FileChannel kick, I figure I should help.
Don't worry about the performance differential. Chances are it's so small, you couldn't even find a way to measure it. In general, you don't take the performance hit for reading 1 or 200 bytes, you take it when you open a connection. It's like walking over to the kitchen: the hard part isn't (usually) grabbing an extra piece of fruit, it's the walk over there. Thus, go ahead and read the entire record, and then see if the deleted or not.
All best,
M
+Pie Number of slices to send: Send
Hi Vlad
My assignment implies that performance isn't an issue. For a findAll(), I just read the flag, if the flag is 0xFF I read past the record and ignore it, if it's 00 I read the record out of the buffer.
HTH
Gareth.
+Pie Number of slices to send: Send
Hi ,
Ok, it means you use "choise !.
Thanx guys!
Vlad
+Pie Number of slices to send: Send
Am I totally out to lunch here or is there some confusion over the value representing the logically deleted flag. My assignment say 0xFF which is -1 is logically deleted (it's 2's complement remember). But this thread seems to indicate people are using 0 and 1, 0x0 and 0x1.
ms
+Pie Number of slices to send: Send
Hi Mike,
We just have different assignements. In my case it is 0/1, in yours probably -1/0, but idea is the same.
Cheers,
Vlad
+Pie Number of slices to send: Send
Hi Mike
Maybe I'm the one who's out to lunch. I thought the -1 value I was getting at first was a corruption caused by reading a signed byte into an int. I switched to using the RAF.readUnsignedByte to get the 0xFF value rather than -1. Then when I swithched to FileChannels I had to mask the byte with &255 to achieve the same thing. I'm not entirely sure I needed to do this, but I'm going to stick with it just in case it was a booby trap put in by SUN.
Cheers
Gareth.
+Pie Number of slices to send: Send
if your assignment says 0xFF that's -1 as a byte.
ms
+Pie Number of slices to send: Send
[Max]: you don't take the performance hit for reading 1 or 200 bytes, you take it when you open a connection.
Well yeah, especially the way you do it, Mr. Open-New-Connection-For-Every-Read. But I agree anyway - a bulk read of 200 bytes takes about the same time as a read of one byte. The hardware and OS are optimized for bulk.
+Pie Number of slices to send: Send
Mike
Thanks for the clarification. Seems I was out to lunch
Cheers
Gareth.
+Pie Number of slices to send: Send
Hi Andrew,
I mentioned about new book of Kathy Sierra & Bert Bates for SJCD jdk1.4.1 Exam. I am not able to find. Can send any link and isbn number of it.
Thanx,
Vlad
+Pie Number of slices to send: Send
Hi Vlad,
You can find it and other books listed on the SCJD FAQ & Links page.
Here is a direct link to Amazon's page for it: Sun Certified Programmer & Developer for Java 2 Study Guide (Exam 310-035 & 310-027). You can get the ISBN and other details there.
From memory, Kathy Sierra and Bert Bates had published the SCJD sections of their book online. They did this because they felt that their book was aimed at the SCJP market, with a bonus section for those going on to SCJD - it was not aimed at people doing SCJD directly. Unfortunately I do not have links for the online pages. Anyone?
Regards, Andrew
A wop bop a lu bop a womp bam boom! Tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1385 times.
Similar Threads
end of file and new IO
NIO read/write review
NX: URLyBird Database Record Number Question
Deleting data form a file?
End of file indication
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 07:02:26.