Cash is no longer king
1 hour ago
@Whereannotation can be put on a Collection to specify additional SQL conditions. The
@LazyCollectionannotation can be used to specify when and how to load a collection. For example, using
LazyCollectionOption.EXTRAtells hibernate to prefer extra queries to overfilling eagerly. This means go beyond Hibernate's normal lazy loading and is useful when dealing with very large collections, since it will cause hibernate to execute
COUNTstatements when accessing the size of an unloaded collection, rather than load the whole collection normally. If you know that you frequently query the size of a large collection without needing any of the actual elements, this boosts performance.
@LazyCollection(LazyCollectionOption.EXTRA). When querying the size of my collection, I was getting a result of 2, yet when I attempted to iterate the collection, the size was returning 0. Excuse me? How is that?
COUNTquery as specified by
@LazyCollection(LazyCollectionOption.EXTRA), Hibernate ignored the
@Whereannotation. When loading the elements of the collection, however, Hibernate correctly minded the
@Whereannotation. Since the
@Wherecondition I was specifying was actually significant, these two methods returned different results.
LazyCollectionOption.EXTRAon any collection that has 2 items, the answer is because it's in early development right now and will not have only 2 items in practice.
messageReceived(which are called when their names would suggest).
<policy-file-request />and respond with the a policy file. The second is to have Flex read the policy file from an alternate location via
Security.loadPolicyFile("wherever")before attempting to open the socket connection. I found the later to be more convenient since it removed the need for my mulitplayer server to know how to handle policy file requests. There are a few restrictions with this route, though.
Security.loadPolicyFile("xmlsocket://localhost:5000");Upon receiving a valid policy file, Flex will then establish the desired socket connection.
socket.flush()would be necessary every time the Flex app writes to the socket. In practice this isn't the case, but you should always flush anyway. I only mention this because it is an oddity. Namely, in Mac OS X browsers, Flex commands written to the socket are received fine by the server without ever flushing the socket on in the Flex client. In Windows browsers, however, failing to flush the socket will cause the command not to be sent on all writes to the socket after the first (the first write will go through fine without flushing). Surprised the hell out of me when I discovered this (which I did by writing the app on a Mac and failing to flush the socket, which worked fine, until I tested it on a Windows machine and found out it wasn't working).